Yes, i entered the API key and user name on the security tab. I want to use TLS
I just signed up for a ThingSpeak account and got TLS working with MQTT.
- server:
mqtt.thingspeak.com - port:
8883 - tick 'Enable secure TLS connection'
- Add a tls-config node - you can leave its values as the defaults.
Hit deploy, and the client connects and I can publish data.
If you don't trust the software to be doing what it says, then you could use a tool like wireshark to examine the packets on the network to see if you can read them or not. But that is way beyond the scope of this forum to help you do.
We've spent a lot of time an energy getting you connected today - when ultimately it just needed you to tick the box to use a TLS connection and make sure you enter the right port according to the ThingSpeak docs.
I appreciate your help, and I apologize for my low-level questions and for wasting your time.
The connection is as secure as TLS allows. Certificate-based security is a slippery subject and has lots of caveats. Mostly about how the server end is handling things. Do they use TLS1.2+ and a current encryption scheme for example or do they allow fallback to less secure versions?
As you have forced a TLS connection and are verifying the servers certificate, that is the best you can hope for. Wire-level checks such as those suggested by Nick would certainly prove exactly what is going on if you have the knowledge to interpret them.
In all honestly, any security issues are going to come either from you misconfiguring your end and allowing access to your device from the Internet or thingspeak misconfiguring their end and allowing unauthorised access.
What additional security do you get with TLS as opposed to wss?
TLS is the method used by most IP-based transports to provide encryption. Used to be SSL but that is no longer considered secure. Older versions of TLS are also no longer considered very secure, TLS 1.0 in particular.
The main thing it gives you is point-to-point encryption managed by public and private certificates on the server end. Your client end maintains a list of public key services so that it can establish a chain of trust with the server (that's what you lose when you chose not to validate the servers certificate - basically the client would except any reasonably formed certificate from anyone).
TLS can also provide 2-way authentication - that is less common but gives a nice seamless login experience when being used. You may have used something similar if you have configured certificate-based logins to SSH for example.
When TLS is in use and correctly configured (which isn't actually that easy to do), you can be sure that you are talking to the correct server and you have an encrypted link between your client and the server. Normally, that means that nobody can intercept the communications (which is why hackers generally find it much easier to hack the client or the server itself).
There are exceptions even there though since badly behaving clients or poorly configured servers may allow man-in-the-middle attacks whereby a proxy intercepts the initial TLS handshake and presents its own certificate to the client. It is then able to intercept and read the traffic. This used to be very common in enterprise environments where the organisation wanted to review traffic from its users for audit and security purposes. Largely discredited as a practice now due to the vulnerabilities it can introduce.
Hope that answers your question Colin - though probably in far more mind numbing detail than you really wanted! 
Not quite, sorry. At least some of that is provided by wss isn't it? Or is that not correct?
WSS is a websocket connection made over a TCP connection that is secured with TLS.
Just as HTTPS is an Http request made over a TCP connection that is secured with TLS.
It's all about the layers.
- TCP Connects
- TLS handshake secures
- Application level protocol (http/ws) communicate
2 Likes
Ok, so wss does use TLS, that's what I thought. So on the mqtt config node when I select wss://... what difference does selecting the SSL/TLS checkbox make? If I leave the ssl config at defaults is there any difference?
It's a little... muddled.
Originally, the node only did TCP. And we wanted to keep it simple and not require the user to start the server address with tcp://. So it made sense to have the tick box to add TLS.
Then the websocket support was added, because the underlying library supported it with no extra work on our part - all it needed was for the broker address to start with ws:// and no other UI updates. And wss:// came for free with that.
So yes, it's a slightly inconsistent set of options and ripe for overhauling.
Sorry, that's the bit I forgot to put in! Got ahead of myself and then forgot - doh!
Nick has explained though.
Ok, so am I right in saying that the answer to the question I originally asked, which was what additional security do you get with TLS as opposed to wss, is nothing, unless you also want the two way authentication?
I'd have to check the code to be sure (which isn't happening tonight). But yes, in theory the TLS config node allows you to provide your own certs etc so you could do mutual authentication.
It's ok, I don't need to do that, just making sure I understand. The original question in this thread was about using TLS/SSL with MQTT, and the answer is, if I understand correctly, that using wss does just that and there is no need to also tick the TLS checkbox. Which is good because that is what I am doing 
I tried wireshark and in the capture tap i've got several interfaces, and the loopback interface contains the local address of the node-red, so i try to capture packets from it, but i've got the same source /destin, TCP or HTTP, when i use inject node to send data, the problem is that i use MQTT to send data and TLS to protect data, but i dont see anything like that here. Any help?
TLS is added to the underlying protocol to get a securely encrypted protocol. In the case of MQTT, you normally would get MQTTS which should be on its own port. By default, you would normally use port 8883 for MQTTS rather than port 1883 for non-encrypted MQTT.
For MQTT over websockets as you are using with Thingspeak, that has its own ports. By the looks of it, it is probably using the default HTTP ports. So port 80 for non-encrypted traffic and port 443 for encrypted.
From wireshark, you should be able to see Node-RED do a handshake with port 443 on the broker when it starts up.
You should then see more traffic on that link whenever you send a msg to MQTT.
Conversely, if you monitor port 80, you should no longer see any traffic.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
