According to the CoAP specification RFC7252 section 5.7 two types of CoAP proxies exists, namely forward-proxy and reverse-proxy.
Orthogonal to this definition a proxy can be CoAP-CoAP or HTTP-CoAP proxy.
I have the following questions according to these definitions:
What are the use cases where each of these proxy types (forward-proxy, reverse-proxy, CoAP-CoAP and HTTP-CoAP) has to be used?
What exactly does the proxy in those use cases?
Which part of the CoAP message does each proxy need in order to accomplish its tasks? (I assume that proxy looks at some of the CoAP options?)
Where runs the proxy? On the boarder router?
It well be very nice if someone can provide in addition to the answers to the questions above also good reverences and examples.
Some use cases for proxy times are:
Forward proxies: Escaping a restrictive firewall (eg. because outgoing connections are blocked unless they go through a proxy); a special case thereof is accessing resources on CoAP from within a browser, when a CoAP-over-WebSocket server is used as a forward proxy.
Reverse proxies: Roughly the same as for forward proxies but in the reverse direction (ie. if the server is in a firewalled network, there can be a reverse proxy running on the firewall that lets requests in selectively). Additionally, reverse proxies can be used for load balancing on the unconstrained server side.
HTTP-CoAP-proxies: Accessing CoAP devices from programming environments that don't have good CoAP support (eg. if your monitoring system supports polling a HTTP server, a H-C proxy easily allows monitoring your CoAP servers).
CoAP-HTTP proxies: Making services on the big web available to constrained devices (eg. querying a weather forecast). This is often of limited use as those web services don't use data formats suitable for a constrained device.
That barely varies over the cases; apart from the obvious (cross-proxies translating CoAP and HTTP messages back and forth), forward and reverse proxies only differ in whether they react to messages with a Proxy-* option (typically Proxy-Scheme) set (forward proxies), or to those without (reverse proxies).
All proxies need to inspect the full message (ie. all header fields and look at all options). Most header fields (token, message-ID, mtype to some extent) and several options (eg. Observe) are hop-by-hop, ie. the server acts on them and creates new values for the forwarded request. If there is anything in the message the proxy would need to understand but doesn't (ie. unknown Proxy-Unsafe options), it rejects forwarding.
That is fully up to the application, but in most of the common examples, that would be some kind of border router; could be the 6LBR in a 6LoWPAN scenario, or the firewall of a larger setup. In cases of routing between a CoAP-over-WebSocket endpoint and the rest of the CoAP world, the CoAP-over-WebSocket server often runs on the same machine that also serves the web application that uses the socket.
Related
I was reading the the official RFC for the Web Sockets protocol in order to implement it for learning purposes, I wanted to make things a bit different somehow but I was not sure what to make different. While I was reading the document, I came across this:
The Web Socket Protocol attempts to address the goals of existing bidirectional HTTP technologies in the context of the existing HTTP infrastructure; as such, it is designed to work over HTTP ports 80 and 443 as well as to support HTTP proxies and intermediaries, even if this implies some complexity specific to then current environment. However, the design does not limit Web Socket to HTTP, and future implementations could use a simpler handshake over a dedicated port without reinventing the entire protocol.
Does this imply a custom web socket protocol can be implemented with a non http based handshake?.
If so, does it mean a the regular Java Script Web Socket client will not work with this and I would need to implement a custom client to communicate using this protocol?
I am looking for a specific kind of proxy that is meant to operate in a rendezvous mode, such that two nodes can make an outgoing connection to the same proxy, send a routing token, and have their packets relayed to each other from that point.
Proxy servers like HAProxy would be perfect but AFAIK they do not offer something like that: the goal of the proxy in this case is to make another outgoing connection and route the packets to that location. In this case, I want two nodes to connect to the proxy, and have their packets relayed between them through the proxy, after sending a routing token that can be used to associate the two nodes.
I could write my own server to perform such type of relaying, but I am wondering if something already exists to do something like this. I am looking for such a solution as a fallback for cases where NAT traversal protocols like ICE/STUN/TURN are not feasible due to a highly restricted network environment that does not allow UDP traffic. The base protocol for the proxy could be TCP, HTTP or WebSocket, which would be easier to allow in a firewall with a simple rule.
Any ideas or recommendations?
I believes SOCKSv5 has everything you are asking for.
two nodes can make an outgoing connection to the same proxy. send a routing token, and have their packets relayed to each other from that point.
The routing token in this case would be the endpoint address and/or the user credentials. I would first look at the supper simple implementation built into the 'ssh' utility, this guide goes over how to get everything set up. If you need something more granular then look into dante.
The only tricky part is when you try to use the user credential option with SOCKv5 as it is not as well supported in browsers, but is possible with addons.
I am trying to capture an old application that didn't honour the system's proxy setting. The only config I can change is the server IP address.
Capturing the packets with Wireshark. Without the Charles reverse proxy, I can see requests after the first three handshake requests.
With the reverse proxy, the connection stuck after the handshake requests.
I notice that when Charles received a request and connecting to somewhere but it will just stuck there:
Following is the config of the reverse proxy (Remote host removed):
Any help, solution and workarounds would be appreciated!
First of all, your app uses neither HTTP nor HTTPS. Studying screen shot of successful connection gives some details on protocol used:
the first message after handhsake is originated by server contrary to common client-server approach, where client is responsible for sending query. This fact is enough to cross out HTTP and HTTPS.
payload data isn't human-readable, so it's a binary protocol.
based on PUSH flags, protocol is much more likely to be message-based rather than stream-based
So client establishes connection, immediately gets some command from server and replies it. Then communication continues. I can't guess exact protocol. Port number might be irrelevant, but even if it's not, there are only few protocols using 4321 port by default. Anyway, it can always be custom private protocol.
I'm not familiar with Charles, but forwarding arbitrary TCP stream is probably covered by its port forwarding feature rather than reverse proxy. However, I don't really see any benefits in sending traffic through Charles in this case, capturing data on your PC should be enough to study details.
If you are looking for traffic manipulation, for arbitrary TCP stream it's not an easy task, but it must be possible. I'm not aware of suitable tools, quick googling shows lots of utils, but some of them looks applicable to text based stream only, so deeper study is required.
Reason for Failure
It may be because you are requesting a local IP address from a remote scope, which Charles proxy doesn't applies. For POS(Proof Of Statement), please refer to the below link
https://www.charlesproxy.com/documentation/faqs/localhost-traffic-doesnt-appear-in-charles/
Solution
So In order to solve the problem for the current scenario, use
http://192.168.86.22.charlesproxy.com/
Note: The url that you request will only be proxied properly by Charles not any other proxy services.
Shall I use WebSocket on non-80 ports? Does it ruin the whole purpose of using existing web/HTTP infrastructures? And I think it no longer fits the name WebSocket on non-80 ports.
If I use WebSocket over other ports, why not just use TCP directly? Or is there any special benefits in the WebSocket protocol itself?
And since current WebSocket handshake is in the form of a HTTP UPGRADE request, does it mean I have to enable HTTP protocol on the port so that WebSocket handshake can be accomplished?
Shall I use WebSocket on non-80 ports? Does it ruin the whole purpose
of using existing web/HTTP infrastructures? And I think it no longer
fits the name WebSocket on non-80 ports.
You can run a webSocket server on any port that your host OS allows and that your client will be allowed to connect to.
However, there are a number of advantages to running it on port 80 (or 443).
Networking infrastructure is generally already deployed and open on port 80 for outbound connections from the places that clients live (like desktop computers, mobile devices, etc...) to the places that servers live (like data centers). So, new holes in the firewall or router configurations, etc... are usually not required in order to deploy a webSocket app on port 80. Configuration changes may be required to run on different ports. For example, many large corporate networks are very picky about what ports outbound connections can be made on and are configured only for certain standard and expected behaviors. Picking a non-standard port for a webSocket connection may not be allowed from some corporate networks. This is the BIG reason to use port 80 (maximum interoperability from private networks that have locked down configurations).
Many webSocket apps running from the browser wish to leverage existing security/login/auth infrastructure already being used on port 80 for the host web page. Using that exact same infrastructure to check authentication of a webSocket connection may be simpler if everything is on the same port.
Some server infrastructures for webSockets (such as socket.io in node.js) use a combined server infrastructure (single process, one listener) to support both HTTP requests and webSockets. This is simpler if both are on the same port.
If I use WebSocket over other ports, why not just use TCP directly? Or
is there any special benefits in the WebSocket protocol itself?
The webSocket protocol was originally defined to work from a browser to a server. There is no generic TCP access from a browser so if you want a persistent socket without custom browser add-ons, then a webSocket is what is offered. As compared to a plain TCP connection, the webSocket protocol offers the ability to leverage HTTP authentication and cookies, a standard way of doing app-level and end-to-end keep-alive ping/pong (TCP offers hop-level keep-alive, but not end-to-end), a built in framing protocol (you'd have to design your own packet formats in TCP) and a lot of libraries that support these higher level features. Basically, webSocket works at a higher level than TCP (using TCP under the covers) and offers more built-in features that most people find useful. For example, if using TCP, one of the first things you have to do is get or design a protocol (a means of expressing your data). This is already built-in with webSocket.
And since current WebSocket handshake is in the form of a HTTP UPGRADE
request, does it mean I have to enable HTTP protocol on the port so
that WebSocket handshake can be accomplished?
You MUST have an HTTP server running on the port that you wish to use webSocket on because all webSocket requests start with an HTTP request. It wouldn't have to be heavily featured HTTP server, but it does have to handle the initial HTTP request.
Yes - Use 443 (ie, the HTTPS port) instead.
There's little reason these days to use port 80 (HTTP) for anything other than a redirection to port 443 (HTTPS), as certification (via services like LetsEncrypt) are easy and free to set up.
The only possible exceptions to this rule are local development, and non-internet facing services.
Should I use a non-standard port?
I suspect this is the intent of your question. To this, I'd argue that doing so adds an unnecessary layer of complication with no obvious benefits. It doesn't add security, and it doesn't make anything easier.
But it does mean that specific firewall exceptions need to be made to host and connect to your websocket server. This means that people accessing your services from a corporate/school/locked down environment are probably not going to be able to use it, unless they can somehow convince management that it is mandatory. I doubt there are many good reasons to exclude your userbase in this way.
But there's nothing stopping you from doing it either...
In my opinion, yes you can. 80 is the default port, but you can change it to any as you like.
I heard from somewhere WebSphere server can be configured to allow only a pre-defined set systems (IPs, domains) to access server contents such as WSDL.
Need help with following questions:
Is this supported?
What are the steps to do the same?
Prerequisites?
Thanks!!
Check this post Ban ip for deny access to an app. It describes various methods (configuring transport channels, http server, or developing custom filter). Although it talks about banning access, same technique can be applied to allow access.
Take notice however that using transport channel will apply to all applications and resources available via given port (not just wsdl). So the solution depends on level of granularity you require.