Very doubtful with an Arduino. But sounds doable with a Pi.

Whilst not exactly what you're looking for, there's a great project called Web Rendering Proxy, which is a shim that uses Google Chrome / Chromium to render pages to images, relay them to the vintage browser of choice, interact with the page, and then send the commands back to the Chrome/Chromium browser in the backend - see here: https://github.com/tenox7/wrp

I am also interested in using the modern Internet from vintage computers.

These days, "Internet" is synonymous with "HTTPS connections serving multiple megabytes of Javascript code", and even my modern i5 laptop with 8GB of RAM struggles to render some of the bloated pages out in the wild. So surely we have to accept some limitations on what is achievable on old hardware.

There's two issues: #1 is HTTPS (since many many sites are now refusing to serve pages over plain HTTP) and #2 is rendering the bloated HTML/CSS/Javascript.

One option to make HTTPS feasible on an ancient CPU is to be aggressive about session reuse: if you only have to do the expensive public key crypto operations when making the first connection to the server, and can then cache the session key in memory for use on subsequent requests, it might work out quite nicely for a use case like "checking a newspaper homepage and then reading several news articles".

Other microcontrollers like eZ80 have a TCP/IP stack, I think.
The most appropriate microcontroller might be the ESP32 or the older ESP8266 perhaps.
These are essentialy programmable WLAN chips, but many thinkers do handle these like more powerful Arduino boards.
Wouldn't be surprised if the Arduino IDE got some kind of support in the meantime. 🙂

Just use ESP8266, and let a proxy handle https -> http conversion

i making esp8266 rs232 modules currently running zimodem
maybe soon i will show them off.

Having DOS SSL support of some sort would be awesome ! I have some project ideas that could benefit from it.

Does openssl compile for msdos with djgpp ?

I'd like to go all the way down to 8088, so DJGPP is out of question here 🙁

Having HTTPS being slow isn't that big of a deal imo, unlike games where you have to do stuff as fast as possible, if getting the content from a web page takes 2 seconds, it's not a big deal, and I'm sure that people using 8088s could be even more patient (now if it takes a minute it could be a problem 🤣)

I've no doubt that the amount of RAM and CPU required for HTTPS encryption would make it horribly slow on vintage equipment.

A Pi based proxy would be nice, so the pages could be served as pure HTTP. Also de crapify pages with the mountains of scripts that run. In the same way that WRP works, a browser within the browser would be ideal to avoid having to configure an actual proxy for browsers that don't support it.

Retro PC connects to proxy page > sends request > page is rendered on proxy device > output HTML is reformatted to a certain level of compliance so it renders correctly on chosen browser (perhaps falling back to image renderings in areas where the browser feature set simply cannot produce a workable page/section) > retro PC reads compliant HTML.

This reminds me a lot of the WAP and i-mode days, when mobile client devices were not powerful enough to handle real websites.
That icab web browser for Mac OS Classic also switched to displaying mobile sites, I recall, because of the same reasons.

Well before starting to look for a hardware solution, I'm really wondering how long it would take on vintage hardware, instead of having just guesses ^^

I think that implementing a modern TLS cipher suite on an 8088 would be an excellent low-level asm coding challenge!

I suspect that the 8087 could help accelerate the public key crypto, too: in addition to floating point, the 8087 can do 64-bit integer arithmetic.

Also, implementing POLY1305-CHACHA20 [a modern cipher suite for TLS 1.2/1.3] ought to be reasonably fast. DJB claims that on an 8-bit AVR (i.e. Arduino) it's possible to do Salsa20 (of which Chacha20 is a variant) in ~300 cycles per byte. And that Poly1305 can be done in ~125 cycles per byte. If we assume that it takes four 8088 clocks to do the equivalent of a single-cycle AVR instruction, then an 8088 ought to be capable of decrypting and authenticating around 3,000 bytes per second. Not blazing fast, but still faster than you'd ever squeeze through a 9600 baud modem!

Obviously the ECDSA/ECDHE public key stuff would take a lot longer, but again I am certain that with session caching it is a non-issue. No big deal to save a few KB of session data in a file on the HDD. The nano-ecc library can perform a 192-bit ECDHE on an 8-bit AVR at 16Mhz in ~4 seconds. That leverages the AVR's 2-cycle 8x8 multiplier hardware, but on an 8088 that could be done via a generated lookup table in 64KB of RAM.

So it doesn't seem beyond the realm of possibility for an 8088 to get "modem-like" performance: think ~30 seconds to "dial" a server (perform the public key exchange) followed by an exchange of data at 14400-28800 baud. With persistent HTTP connections and request pipelining, the single connection can be used to handle an entire browsing session.

Who wants to get their hands dirty and write some tight x86 assembly routines? 😀

kdr wrote on 2020-10-11, 21:47:

Who wants to get their hands dirty and write some tight x86 assembly routines? 😀

Why not do it yourself ?
You already know where to start!
Now Start Off!

I really would see your efforts 😀

matze79 wrote on 2020-10-12, 08:03:

Why not do it yourself ? You already know where to start! Now Start Off! […]
Show full quote

Why not do it yourself ?
You already know where to start!
Now Start Off!

I really would see your efforts 😀

I've been working my way up to it!

Since I'm being pedantic and insisting on using only the tools that are era-appropriate, there has been a somewhat steep learning curve involved.I've finally gotten to the point where I have a decent Turbo XT machine with a usable MDA monitor [no way am I gonna write code in CGA textmode ughhhh], working hard drive and reliable Ethernet card and proper development tools... Turbo C 2.0, TASM 1.0, Turbo Debugger 1.0, and of course the glorious DOS 3.3 version of DEBUG.COM just in case. 😀

I like to pretend that my XT is still living in 1989 but somehow got its Ethernet cable caught in a wormhole and started receiving packets from my 2020 LAN.... it just doesn't know what to do with those packets (yet).

Using mTCP for this project could be another starting point as the https support could then be ported to all the mTCP suite ^^
(And prevent you from reinventing the wheel for TCP/IP support on 8088)

Some general comments ...

Encryption on older DOS machines: Everybody points out the obvious - that mTCP doesn't have an SSH client. I've looked into what it would take and there are two significant problems:

1. Processing speed. For modern ciphers at reasonable bit lengths you don't have enough CPU power. I suspect the cut-off for usability is somewhere around 200Mhz Pentium running 32 bit code, but nobody really knows because you'd have to measure it. The best way to try to measure this would be to use a Linux with an up-to-date SSL library on old hardware and see how bad that is. Oh, and the requirements keep getting heavier, so expect that line to move to faster machines each year or two.
2. Library support: The libraries are big moving targets. Porting them to DOS and keeping them up to date would be very difficult. Think about the ciphers, the certificate management, and all of the associated libraries. We just don't have that army of DOS programmers available.

And so the possible solutions:

• Use a proxy that can do the heavy lifting and present something simplified to your machine. Right now the heavy lifting is the encryption and Javascript. If you go down this path at some point you will realize that the DOS part of what you are building is just a remote screen handling function. If you go low level you've re-invented VNC or X, and if you go higher level you recognize links, clickable areas like mouse events, etc. But whatever level you choose, you are still basically just the UI for the thing doing the work.
• Use an onboard co-processor to do the heavy lifting. This approach gets you around the CPU limitations. It might enable SSH on a low-end machine but you still can't implement a web browser because of Javascript and all of the other complexities. (Somebody has already bolted on a Raspberry PI 0 onto a PCjr through the jrIDE interface as an experiment. If you think creatively you can enable a lot of new things, but you are also basically hiding a full Linux machine in your retro computer so except for the interfacing, how novel is that?)

If somebody wants to arrange a time for a chat on IRC or Discord I'd be happy to bounce ideas around. I'm also happy to help people get up to speed with DOS programming. It's good to be slightly unreasonable as it is the unreasonable people in the world who force major changes, but don't go overboard - a 30 year old DOS clone is not joining the modern Internet, and the modern Internet keeps evolving and getting more complex.

mbbrutman wrote on 2020-10-12, 16:07:

Some general comments ... […]
Show full quote

Some general comments ...

Encryption on older DOS machines: Everybody points out the obvious - that mTCP doesn't have an SSH client. I've looked into what it would take and there are two significant problems:

1. Processing speed. For modern ciphers at reasonable bit lengths you don't have enough CPU power. I suspect the cut-off for usability is somewhere around 200Mhz Pentium running 32 bit code, but nobody really knows because you'd have to measure it. The best way to try to measure this would be to use a Linux with an up-to-date SSL library on old hardware and see how bad that is. Oh, and the requirements keep getting heavier, so expect that line to move to faster machines each year or two.
2. Library support: The libraries are big moving targets. Porting them to DOS and keeping them up to date would be very difficult. Think about the ciphers, the certificate management, and all of the associated libraries. We just don't have that army of DOS programmers available.

Actually, the current situation isn't quite so bad. I managed to get SSHDOS running nicely on my 486DX2/66, and after some tweaking of my server's sshd.conf to re-enable some of the ancient cipher suites I am able to SSH and SFTP with ease. Based on the SFTP speeds that I get over the local network (> 200KB/sec), this ought to also be usable on a 386 as well... there's a bit of a pause (2-3 seconds?) while the initial key exchange takes place but after that it's all symmetric crypto and proceeds at a reasonable speed.

Direct ports of modern network/crypto libraries are infeasible, the bloat is simply unmanageable.

But I have high hopes for what hand-optimized 8088/V20 code can achieve. The usual problem with embedded TCP/IP and crypto stacks is a lack of RAM (think 4KB-32KB total) and code/data storage (64KB-512KB), and thankfully on an XT class machine we've got hundreds of kilobytes of RAM and tens of megabytes of disk to work with. And yet another difference is that modern crypto code tends not to use lookup tables, because in a system with memory caches, data-dependent memory reads leak secrets through timing analysis.

EDIT to add: and now I realize exactly who it is that I'm replying to. Cheers for your awesome work on mTCP, it's so much fun to be able to telnet and FTP from my turbo XT thanks to your code!

kdr wrote on 2020-10-12, 09:28:

I've been working my way up to it! […]
Show full quote

matze79 wrote on 2020-10-12, 08:03:

Why not do it yourself ? You already know where to start! Now Start Off! […]
Show full quote

Why not do it yourself ?
You already know where to start!
Now Start Off!

I really would see your efforts 😀

I've been working my way up to it!

Since I'm being pedantic and insisting on using only the tools that are era-appropriate, there has been a somewhat steep learning curve involved.I've finally gotten to the point where I have a decent Turbo XT machine with a usable MDA monitor [no way am I gonna write code in CGA textmode ughhhh], working hard drive and reliable Ethernet card and proper development tools... Turbo C 2.0, TASM 1.0, Turbo Debugger 1.0, and of course the glorious DOS 3.3 version of DEBUG.COM just in case. 😀

I like to pretend that my XT is still living in 1989 but somehow got its Ethernet cable caught in a wormhole and started receiving packets from my 2020 LAN.... it just doesn't know what to do with those packets (yet).

Great 😀 !!!!