HTTP Proxies and MQTT

[Dominik Obermaier]

Corporate networks typically block most outgoing ports. Unfortunately in most corporate networks port 1883 and 8883 are also blocked, which makes it hard for MQTT applications to connect to any broker that resides outside the corporate network. Port 80 and 443 are not optimal for MQTT traffic if there’s a HTTP Proxy deployed.

What are the best practices for reaching outside MQTT brokers in restricted networks, especially if a HTTP proxy is in place? 

The following possibilities are the most obvious ones for me, all of them are not optimal, though:

* Use a port that is not blocked (e.g. 22, 25, …) => This may provoke a conflict with the network administrators

* Use MQTT over (secure) websockets. This may work with some HTTP Proxies if websockets are supported.

* Use port 443 in case the proxy just forwards encrypted traffic

* Use HTTP CONNECT

I’d say the best approaches would be the HTTP CONNECT approach or the websockets approach. While websockets are widely adopted amongst MQTT libraries (e.g. Paho Java also seems to include websocket support soon), I am not aware of any MQTT library that supports HTTP CONNECT. 

Does anyone have more insights on the HTTP Proxy + MQTT topic?

Thanks,

Dominik

[Jan-Piet Mens]

>* Use a port that is not blocked (e.g. 22, 25, …) => This may provoke a
>conflict with the network administrators

I think it's bad manners to use a well-known port like that, in particular
because that well-known port may, at a later stage, be used for what it's
designed to carry.

>* Use MQTT over (secure) websockets. This may work with some HTTP Proxies if
>websockets are supported.

I think proxies with websocket support exist, but I've not come accross that
myself.

>* Use port 443 in case the proxy just forwards encrypted traffic

This is unlikely to work in an environment which uses proxied 443 for HTTPS

>(e.g. Paho Java also seems to include websocket support soon)

as does Paho Python 1.2 and Christoph's MQTTClient for iOS.

I too think the CONNECT approach would be safest, if libraries supported it.

-JP

[Dominik Obermaier]

JP, thanks for your thoughts on this! I agree that using well-known ports may not be the best idea. 

It really seems to resolve the HTTP Proxy issue, the popular MQTT libraries like Paho need to support HTTP CONNECT on their side. Does anyone know if there are efforts ongoing to support the proxy traversal?

Thanks,

Dominik

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[Ari Volcoff]

I'm having the same issue 

have you found a solution for this ?

[Dominik Obermaier]

Hi Ari,

from my point of view the only viable solution for corporate proxies is that the MQTT libraries support HTTP CONNECT. I recently saw on Twitter that someone tried this with Paho Python, but I haven’t seen an implementation so far. I unfortunately don’t have the link at hand to this conversation right now.

With Paho Java, this would also need a HTTP CONNECT “flow” before establishing the actual connection with the broker. This would be doable with a custom SocketFactory and a Socket Wrapper that does the HTTP CONNECT first. 

MQTT and HTTP Proxies seem to be one of the hardest challenges nowadays in corporate networks, I hope that the library maintainers are considering first-class Proxy support in future versions.

Dominik

[Nicholas Humfrey]

Hello,

My experience is that HTTP proxies are sometimes configured to timeout
long-running connections and there is a preference for using SOCKS
instead. This is because on the web HTTP connections are usually very
short - leaving connections open, you are using up capacity on the HTTP
server.

Depending on the language it is possible to either generically wrap up
at the language/library level or even at the system call level using a
'shared library interceptor':
http://tsocks.sourceforge.net/

My personal preference for tunnelling out of an enterprise environment,
is to use socat to port forward to a port bound to localhost. Although I
appreciate that this is far from straightforward for endusers. But maybe
that is what the 'Enterprise' setup is aiming for?


nick.

>> To learn more about MQTT please visit http://mqtt.org [1]

>> ---
>> You received this message because you are subscribed to the Google
>> Groups "MQTT" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to mqtt+uns...@googlegroups.com.
>> To post to this group, send email to mq...@googlegroups.com.

>> Visit this group at https://groups.google.com/group/mqtt [2].
>> For more options, visit https://groups.google.com/d/optout [3].

> --
> To learn more about MQTT please visit http://mqtt.org
> ---
> You received this message because you are subscribed to the Google
> Groups "MQTT" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mqtt+uns...@googlegroups.com.
> To post to this group, send email to mq...@googlegroups.com.
> Visit this group at https://groups.google.com/group/mqtt.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> To learn more about MQTT please visit http://mqtt.org
> ---
> You received this message because you are subscribed to the Google
> Groups "MQTT" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mqtt+uns...@googlegroups.com.
> To post to this group, send email to mq...@googlegroups.com.
> Visit this group at https://groups.google.com/group/mqtt.
> For more options, visit https://groups.google.com/d/optout.
>
>

> Links:
> ------
> [1] http://mqtt.org
> [2] https://groups.google.com/group/mqtt
> [3] https://groups.google.com/d/optout