HTTP to HTTPS conversion device? - Page 1
Forum section: electronics / general

author: AlbertL
author_rank: Regular Contributor
timestamp: December 22, 2021, 05:49:07 pm
content: 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.

author: madires
author_rank: Super Contributor
timestamp: December 22, 2021, 06:30:45 pm
content: RasPi + squid + script to rewrite the URL

author: pqass
author_rank: Super Contributor
timestamp: December 22, 2021, 06:34:46 pm
content: stunnel is available for various Linux, FreeBSD, others:https://www.elastic.co/guide/en/cloud/current/ec-tunneling-ssl.htmlhttps://blog.thesysadmins.co.uk/using-stunnel-to-encrypt-unsecure-connections.htmlhttps://www.stunnel.org/https://www.freebsd.org/cgi/ports.cgi?query=stunnel&stype=allFrom the man page:https://www.stunnel.org/static/stunnel.htmlPLC connects to stunnel gateway, gateway calls HTTPS service.In the example below, in on 143 out toservername:993Quote

author: AlbertL
author_rank: Regular Contributor
timestamp: December 22, 2021, 06:48:40 pm
content: Quote from: madires on December 22, 2021, 06:30:45 pmThanks - 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.

author: madires
author_rank: Super Contributor
timestamp: December 22, 2021, 07:03:47 pm
content: Less than 5 seconds shouldn't be any problem.

author: golden_labels
author_rank: Super Contributor
timestamp: December 22, 2021, 08:00:04 pm
content: 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 likesystemd-random-seed, if the system is allowed to modify the relevant file on the root file system.(1)If that is not available, there are things like Neil Horman’srng-tools— offering asystemdservice 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.____(1)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.

author: AlbertL
author_rank: Regular Contributor
timestamp: December 22, 2021, 08:15:04 pm
content: Quote from: madires on December 22, 2021, 07:03:47 pmGreat, I will definitely check it out!

author: PKTKS
author_rank: Super Contributor
timestamp: December 24, 2021, 09:05:00 am
content: While squid should work..It requires cache space and several child forks....Why not just porting TSOCKS and tunnel all your traffic...PaulPS> For the record.. RPIshouldhave the socks gatewayfrom debian already ready..https://www.inet.no/dante/http://ftp.de.debian.org/debian/pool/main/t/tsocks/Paul

author: peter-h
author_rank: Super Contributor
timestamp: December 25, 2021, 07:43:28 am
content: 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.

author: PKTKS
author_rank: Super Contributor
timestamp: December 25, 2021, 08:35:58 am
content: For now it sure works on RPI..But not cheapI am closing following ESP32I have a hunch in a few time windowIt will surpass all options...Cheap and very very goodPaul

author: NiHaoMike
author_rank: Super Contributor
timestamp: December 25, 2021, 02:36:38 pm
content: Just get a router with VPN support (e.g. Mikrotik) and configure the server to tunnel the connection over VPN?

author: PKTKS
author_rank: Super Contributor
timestamp: December 26, 2021, 08:42:11 am
content: Quote from: NiHaoMike on December 25, 2021, 02:36:38 pmThis is optimal for our bench or officeBut 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 pocketsPaul

author: Foxxz
author_rank: Regular Contributor
timestamp: December 27, 2021, 05:38:50 am
content: I will second the approach using stunnel on a pi or whatever. Its fast and easy. It won't have any issue with speed.

author: peter-h
author_rank: Super Contributor
timestamp: December 27, 2021, 06:40:54 am
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: December 27, 2021, 06:53:10 am
content: 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?

author: AlbertL
author_rank: Regular Contributor
timestamp: December 27, 2021, 01:22:39 pm
content: Quote from: peter-h on December 27, 2021, 06:40:54 amThanks; it's for just one site at the moment. Your product sounds like what I'm looking for: something plug-and-play, and transparent.

author: peter-h
author_rank: Super Contributor
timestamp: December 27, 2021, 05:07:22 pm
content: Well, plug and play isn't possible once you realise that this "box" needs to store about 200k's worth of root certificatesAnd somehowsecurelyupdate 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.

author: mariush
author_rank: Super Contributor
timestamp: December 27, 2021, 05:50:39 pm
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 27, 2021, 06:34:36 pm
content: I'll have a look at QUIC, it seems interesting.

author: gf
author_rank: Super Contributor
timestamp: December 27, 2021, 09:39:25 pm
content: Quote from: AlbertL on December 22, 2021, 05:49:07 pmIf particularly the TLS connection establishment is the bottleneck, what about keeping the connection alive and sending subsequent HTTP requests over the same connection?

author: peter-h
author_rank: Super Contributor
timestamp: December 28, 2021, 07:16:48 am
content: 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

author: gf
author_rank: Super Contributor
timestamp: December 28, 2021, 09:20:24 am
content: 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.