io.tlssocket: how to ignore certificate check?

[tve]

How do I tell TLSsocket (ecma 419 version) to ignore the certificate validity, e.g. for self-signed certificates? It seems that's something left out of the 419 standard?

[phoddie]

It doesn't seem to be in the spec, though it was intended to be.

The TLS implementation supports that by setting the verify flag to false. It may be that the intended name for 419 is different (I don't have time to run that down now, but I think it is supposed to match the equivalent Node flag). This works in httpclient example to disable certificate verification:

const http = new device.network.http.io({ 
	...device.network.http,
	host: "www.google.com",
	port: 443,
	socket: {
		io: TLSSocket,
		TCP: device.network.http.socket,
		secure: {
			verify: false
		},
	}
});

[phoddie]

For mqtt.js, you will need to change the code to handle mqqts: and to disable verification. The TLS setting is the same though.

mqttClient with TLS works. Node-RED MCU uses that.

The auth error you see if the client (local device) reporting that it couldn't verify the certificate provided by the server. So, you haven't disabled verification.

If you are hitting that certificate auth err, I believe that means you are using a client specific certificate, not just a self-signed certificate. That works too (Node-RED MCU supports it too).

[tve]

Q: is TLS implemented in javascript or does it use mbedtls or something else underneath?

The real question I have is whether one can affect the max send fragment size and max recv fragment size. Being able to set the former to something "small", like 4KB, saves 24KB over the TLS default 32KB. I see that there's a 16KB constant for the recv fragment size in the code...

[phoddie]

TLS implemented in JavaScript (with all the heavy lifting crypto and such in native code). You can step in to see that.

The real question I have is whether one can affect the max send fragment size and max recv fragment size. Being able to set the former to something "small", like 4KB, saves 24KB over the TLS default 32KB. I see that there's a 16KB constant for the recv fragment size in the code...

In theory, yes. But, actually, more-or-less no servers implement support for the client requesting that. I've spent more time on that over the years than I care to admit. So, the client has to deal with what the server decides.

[tve]

The client is in control of the send fragment size, though.

[phoddie]

The send size is based on what you write. It doesn't buffer beyond that. The receive, of course, is decided by the server.