HTTP to HTTPS conversion device?

[AlbertL]

I have a programmable logic controller at a remote site that's pushing data to a server via HTTP at 5-second intervals, but I'd like to move to HTTPS.  The PLC has TLS capability so it can do HTTPS, but it doesn't have a specialized encryption processor so the handshake is very slow - in the range of 8-15 seconds to establish a connection.

So I'm wondering: does anyone make a fast, transparent converter that would accept HTTP messages from the PLC, forward them to the server via HTTPS, and pass the response back to the PLC as HTTP?  I think what I want is a "TLS termination proxy", but in a stand-alone hardware package.

[madires]

RasPi + squid + script to rewrite the URL

[pqass]

stunnel is available for various Linux, FreeBSD, others:
https://www.elastic.co/guide/en/cloud/current/ec-tunneling-ssl.html
https://blog.thesysadmins.co.uk/using-stunnel-to-encrypt-unsecure-connections.html
https://www.stunnel.org/
https://www.freebsd.org/cgi/ports.cgi?query=stunnel&stype=all

From the man page:  https://www.stunnel.org/static/stunnel.html
PLC connects to stunnel gateway, gateway calls HTTPS service. 
In the example below, in on 143 out to servername:993

In order to let your local e-mail client connect to a TLS-enabled imapd service on another server, configure the e-mail client to connect to localhost on port 119143 and use:

    [imap]
    client = yes
    accept = 143
    connect = servername:993

[AlbertL]

RasPi + squid + script to rewrite the URL

Thanks - that's an interesting approach.  Do you have any feel for the speed of TLS in that environment?  As I mentioned, sending HTTPS message from my PLC takes about 8-15 seconds; that's to open the TCP connection, do the TLS handshaking and send < 1KB of data.  I'd want to get that under 5 seconds.     

[madires]

Less than 5 seconds shouldn't be any problem.

[golden_labels]

Be aware that microcontrollers, similar to VPS-es, usually lack good source of entropy. That has two implications.

How fast your services can start and handle requests depends on software and configuration. That may range from immediate start and no delays, to waiting minutes on each request. For example on current Linux based systems and with properly written software you should expect an initial delay, after which requests will be handled quickly. The situation may be further remedied by tools like systemd-random-seed, if the system is allowed to modify the relevant file on the root file system.⁽¹⁾ If that is not available, there are things like Neil Horman’s rng-tools — offering a systemd service that tries to speed up gathering entropy — or platform-specific solutions for architectures offering hardware generators.

The other thing is: avoid trusting unauditable solutions, unless the manufacturer puts money where their mouth is. It’s way too easy to fake cryptography and it’s very hard to prove that by just looking at the data streams. If it handles requests quickly since start, but there is no sign of any fast entropy source, it’s an extra warning sign. Of course it’s always possible they applied solutions equivalent to ones mentioned above, but experience with such products is not on their side.
____
⁽¹⁾ See the documentation, as by default that will not bump entropy counter to avoid using a read-only file or a value that has never been initialized.

[AlbertL]

Less than 5 seconds shouldn't be any problem.

Great, I will definitely check it out!

[PKTKS]

While squid should work..
It requires cache space and several child forks....

Why not just porting TSOCKS and tunnel all your traffic...

Paul

PS>  For the record.. RPI should have the socks gateway
from debian already ready..

https://www.inet.no/dante/
http://ftp.de.debian.org/debian/pool/main/t/tsocks/

Paul

[peter-h]

To do this in an embedded system, one which doesn't run "unix", you need TLS, and there is stuff like MbedTLS. This is complex code and AFAICT most of these libs are buggy, and need a lot of FLASH and RAM. I am involved in a project where move from the (unusuably buggy) PolarSSL to MbedTLS increased the code size by about 150k and the RAM usage is about 40-50k. With a ST 32F417 at 168MHz it is fast enough though not spectacular, taking a few secs.

Unfortunately the world is going "civil liberties" and "security everywhere even when it is completely irrelevant" so HTTPS is necessary. Eventually browsers will not work for HTTP sites anymore.

[PKTKS]

For now it sure works on RPI..
But not cheap

I am closing following ESP32

I have a hunch in a few time window
It will surpass all options...
Cheap and very very good

Paul

[NiHaoMike]

Just get a router with VPN support (e.g. Mikrotik) and configure the server to tunnel the connection over VPN?

[PKTKS]

Just get a router with VPN support (e.g. Mikrotik) and configure the server to tunnel the connection over VPN?

This is optimal for our bench or office

But you can not take that with you and attach anywhere..

As you can with a RPI installed socks gateway  with all your apps..

Small light.. can even be on pockets

Paul

[Foxxz]

I will second the approach using stunnel on a pi or whatever. Its fast and easy. It won't have any issue with speed.

[peter-h]

Is this a one-off, or volume?

I have a product which could do this job, as a custom programmed inline converter. Industrial, DIN rail mounted.

[Jeroen3]

What I often see in plc cabinets is an Ewon Cosy or Tosibox. It's used for remote management of machines, but it can do more.
Basically it's a VPN where the PLC is on the client side, eg: no port forwarding needed.
It's managed (also not free), so perhaps a bit safer than DIY-ing with rpi. Since who's patching those?

[AlbertL]

Is this a one-off, or volume?

I have a product which could do this job, as a custom programmed inline converter. Industrial, DIN rail mounted.

Thanks; it's for just one site at the moment.  Your product sounds like what I'm looking for: something plug-and-play, and transparent.

[peter-h]

Well, plug and play isn't possible once you realise that this "box" needs to store about 200k's worth of root certificates

And somehow securely update them - just like your browser does.

That's unless you are just talking to a private server, in which case you can stick a 50 year self-signed certificate on that. But if you are only ever talking to a private server, you don't need HTTPS. You can just encrypt the data with some shared key.

This is one of the dilemnas of "secure IOT". There is no solution for authenticating the host.

[mariush]

May want to have a look at HTTP/3 which is moving to using QUIC and UDP instead of tcp and supposedly has better encryption ( faster handshakes, 0-RTT (round-trip-time) )

As an alternative, would your client it be possible to upload the content as encrypted archives? Could have the password dynamically generated based on date or other parameters , or some seed, encrypt the list of file names in the archive, add some bogus file entries before and after actual content with a few random bytes to make it harder to decrypt the archives if intercepted 

[SiliconWizard]

I'll have a look at QUIC, it seems interesting.

[gf]

I have a programmable logic controller at a remote site that's pushing data to a server via HTTP at 5-second intervals, but I'd like to move to HTTPS.  The PLC has TLS capability so it can do HTTPS, but it doesn't have a specialized encryption processor so the handshake is very slow - in the range of 8-15 seconds to establish a connection.

If particularly the TLS connection establishment is the bottleneck, what about keeping the connection alive and sending subsequent HTTP requests over the same connection?

[peter-h]

If you control the server, then you can. Otherwise, most will time out.

And if you control the server, most of this stuff can be avoided anyway

[gf]

For HTTP 1.1 requests, "Connection: Keep-Alive" is actually the default, so it is not unusual that today's web servers support it. But yes, the server is still free to respond with a "Connection: close" header (possibly depending on its configuration). If you cannot control the server, it is at least worth to test whether the server honors it.