Looks like TLS 1.3 has been made to work on Windows 3.1. Can the same be done for System 7?

[sailingdarter]

In my web crawling today I came across an article about a WinGPT client for Windows 3.x. In that piece there was a paragraph where a developer was able to coax a TLS Library into building on a early 1990s version of Windows.

Modern TLS/SSL on 16-bit Windows

It got me thinking, right now it is simply accepted that Classic Mac OS is locked out TLS secure internet without proxies. But after seeing something like this, I am wondering if that is enough to give the problem a "second look" on Classic Mac OS.

Honestly I have zero programming experience in Classic Mac OS (Aside from dabbling in RealBasic as a teenager) so I am not sure that this has already been written off by people more knowledgeable but it is something that would pique my interest.

 

[Nixontheknight]

In my web crawling today I came across an article about a WinGPT client for Windows 3.x. In that piece there was a paragraph where a developer was able to coax a TLS Library into building on a early 1990s version of Windows.

Modern TLS/SSL on 16-bit Windows

It got me thinking, right now it is simply accepted that Classic Mac OS is locked out TLS secure internet without proxies. But after seeing something like this, I am wondering if that is enough to give the problem a "second look" on Classic Mac OS.

Honestly I have zero programming experience in Classic Mac OS (Aside from dabbling in RealBasic as a teenager) so I am not sure that this has already been written off by people more knowledgeable but it is something that would pique my interest.

I'm no expert, but I feel like it would probably require Open Transport, as it might not work with the old MacTCP stack, so it might require 7.5 or newer, up to OS 9.2.2, including Classic Environment

 

[zigzagjoe]

Unfortunately, the problem is less the availability of code to do TLS as it is the computational overhead involved with the key exchange and ongoing encryption.

One key exchange is takes an excessive amount of time even on a fairly performant CPU of this vintage, and when a page load could require multiple key exchanges between various hosts (or even the same, if keep alive isn't used)... it's just not very practical.

Edit; for 68K based machines. PowerPCs should be able to do it.

 

[sailingdarter]

Unfortunately, the problem is less the availability of code to do TLS as it is the computational overhead involved with the key exchange and ongoing encryption.

One key exchange is takes an excessive amount of time even on a fairly performant CPU of this vintage, and when a page load could require multiple key exchanges between various hosts (or even the same, if keep alive isn't used)... it's just not very practical.

Edit; for 68K based machines. PowerPCs should be able to do it.

I see your point on modern TLS browsing for 68K machines.

But for more focused clients that are not web browsers,I guess I am a little more optimistic, If the above Windows 3.x example was able to get it working on 486 class hardware with a ChatGPT client I think that a 68040 should be able to do it as well.

But I think that it would be an interesting exercise.

 

[sailingdarter]

I'm no expert, but I feel like it would probably require Open Transport, as it might not work with the old MacTCP stack, so it might require 7.5 or newer, up to OS 9.2.2, including Classic Environment

Even if it was restricted to OpenTransport that would cover all hardware with a 68030 and later.

 

[Snial]

You'd probably want to pick an embedded implementation, e.g. LwIP, because those systems are closer to the computational capabilities of 68K Macs.

lwIP: TLS layer

GitHub - wolfSSL/wolfssl-examples: Example applications using the wolfSSL lightweight SSL/TLS library

Example applications using the wolfSSL lightweight SSL/TLS library - GitHub - wolfSSL/wolfssl-examples: Example applications using the wolfSSL lightweight SSL/TLS library

github.com

Eliptic Curve encryption algorithms might be low-resource enough to be usable (and I think they use fixed point arithmetic, so that would help too).

To my mind though the most obvious use for TLS would be to get an email client e.g. Eudora (1.3.1?) updated to use TLS. I would suspect you only need a single key to do that and timeouts wouldn't be so critical. Next up would be the equivalent of SSH?

MacGUI was working on a new, secure library for 68K machines, but it seems to have stalled.

Mac GUI :: Sabina TCP/IP Progress and Development Log

Apple news, photo galleries, downloads, and discussion forums.

macgui.com

 

[cy384]

mbedtls can be built with retro68, I use it for ssheven. A 68030 barely has the horsepower to do SSH without timing out. Web browsing would be pretty miserable.

The problem is that you can't really bolt this into any 90s applications, even ones with the source available would be a lot of work. Maybe someone could write a proxy that runs on the Mac and handles the TLS/SSL, for applications that support using a proxy, but that doesn't give a huge amount of benefit vs. just running the proxy on some other, faster.

 

[paws]

There is this:

GitHub - classilla/cryanc: TLS for the Internet of Old Things

TLS for the Internet of Old Things. Contribute to classilla/cryanc development by creating an account on GitHub.

github.com

Although it looks like it's at an early stage as far as the Mac goes. It's based on a different TLS library than the Windows project linked. I don't know if it'd be easier to get WolfSSL to compile and turn that into something usable.

But as @cy384 says there's more to it than just making a library if you want to use existing applications. If someone wanted to write, say, a native Mac Mastodon client or something it might work, though.

 

[uyjulian]

RSA signatures are definitely slow, but ed25519 signatures might give you better performance.

 

[CC_333]

The DSPs in the Quadra 840/660av might be useful in this case?

I think this has been examined before, and nobody could figure out how to program them, nor could they find the necessary toolkits to do so, but I could be confusing it with something else....

c

 

[Nixontheknight]

The DSPs in the Quadra 840/660av might be useful in this case?

I think this has been examined before, and nobody could figure out how to program them, nor could they find the necessary toolkits to do so, but I could be confusing it with something else....

c

and the DSPs built into PowerPC chips might help as well

 

[cluster_fsck]

Late to this thread but you might want to check out a fork of PolarSSL for classic Mac OS - it's not currently compiling for me on Mac OS X Tiger, but I'm working on some tweaks to see if I can get it running. There's an included CodeWarrior project but there's an issue with building a classic Mac OS shared library that I'm working on as well. My only issue is lack of time given that my day job is bananas.

Running SSL encrypt/decrypt on 68k Macs seems like an exercise in terror. I like the idea of potentially offloading processing to something like the AT&T DSP that was included in the Quadra AV models -- Apple had a small OS that actually runs on that chip called Apple RTOS that was used for handling voice recognition features for those models. I'd not put much hope in using that DSP to do the processing. It's one thing to get SSL running on System 7 (like Windows 3.1) but the most important aspect is the processor and whether it supports the right type of instructions for acceleration as well as enough of a memory footprint.

The most likely path to getting any kind of modern SSL running in using a library like PolarSSL embedded into an application. Even then you need some additional layers to make networking calls, either through MacTCP or Open Transport, something to handle HTTP, something to handle modern authentication (like OAuth), and finally something to handle JSON. I have yet to find a Mac OS-specific JSON handling library, but there are some out there for XML-RPC (including AppleScript and it may even be built into URL Access). AFAIK, Core Foundation's XML Parser was only available on Mac OS X and not on CarbonLib apps on classic Mac OS (the headers for CFXMLParser are included in Universal Headers 3.4.2).

Anyway, I'm working on a small, toy Mastodon client for classic Mac OS and my goal is for it to be self-contained and not require a donor computer running a SSL-stripping proxy. It's a long journey but kinda fun even with all of the roadblocks above.

 

[halkyardo]

Late to this thread but you might want to check out a fork of PolarSSL for classic Mac OS - it's not currently compiling for me on Mac OS X Tiger, but I'm working on some tweaks to see if I can get it running. There's an included CodeWarrior project but there's an issue with building a classic Mac OS shared library that I'm working on as well. My only issue is lack of time given that my day job is bananas.

Running SSL encrypt/decrypt on 68k Macs seems like an exercise in terror. I like the idea of potentially offloading processing to something like the AT&T DSP that was included in the Quadra AV models -- Apple had a small OS that actually runs on that chip called Apple RTOS that was used for handling voice recognition features for those models. I'd not put much hope in using that DSP to do the processing. It's one thing to get SSL running on System 7 (like Windows 3.1) but the most important aspect is the processor and whether it supports the right type of instructions for acceleration as well as enough of a memory footprint.

The most likely path to getting any kind of modern SSL running in using a library like PolarSSL embedded into an application. Even then you need some additional layers to make networking calls, either through MacTCP or Open Transport, something to handle HTTP, something to handle modern authentication (like OAuth), and finally something to handle JSON. I have yet to find a Mac OS-specific JSON handling library, but there are some out there for XML-RPC (including AppleScript and it may even be built into URL Access). AFAIK, Core Foundation's XML Parser was only available on Mac OS X and not on CarbonLib apps on classic Mac OS (the headers for CFXMLParser are included in Universal Headers 3.4.2).

Anyway, I'm working on a small, toy Mastodon client for classic Mac OS and my goal is for it to be self-contained and not require a donor computer running a SSL-stripping proxy. It's a long journey but kinda fun even with all of the roadblocks above.

The discussion of offload of SSL operations has got me thinking... it would be fairly machine-specific, but the ethernet chip I'm using for my SE and SE/30 ethernet card project can do modular exponentiation (i.e. the computationally-expensive bit of RSA), MD5 and SHA1 in hardware (it is supposed to also do AES, but according to the errata, the AES hardware is buggy and should not be used).

At this point I haven't put any effort in exposing that functionality in the driver, just because I could never see myself writing code to take advantage of it, but if other folks are interested in making use of it, I could put it on the to-do list.

In theory it wouldn't be all that hard to adapt the design to other 68k PDS slots, or even build a NuBus version of the card, so its applications aren't entirely limited to compact macs in the long run.

 

[cy384]

Anyway, I'm working on a small, toy Mastodon client for classic Mac OS and my goal is for it to be self-contained and not require a donor computer running a SSL-stripping proxy. It's a long journey but kinda fun even with all of the roadblocks above

I extremely strongly recommend retro68 instead of vintage compilers if you want to use modern OSS libraries. A basic build of mbedtls was mostly tricky cmake/config setup instead of a completely intractable missing headers and missing compiler feature slog.

I could give some pointers if you're interested. Libraries that don't use posix features or directly do I/O are relatively easy to use, and good libraries meant for embedded systems are careful to be extremely portable.

At this point I haven't put any effort in exposing that functionality in the driver, just because I could never see myself writing code to take advantage of it, but if other folks are interested in making use of it, I could put it on the to-do list.

To be useful, it would need the driver part, mbedtls changes to use it, and new applications that need the speed, and also would only be useful to people with the hardware. All doable, but the vintage mac software development ecosystem is so small, it would be a shame to ask you to do the work with such a small chance/amount of payoff.

I would be interested to see if a 68040 can do TLS unaccelerated. I think it's only like a weekend of messing around, I may try to make a little proof of concept program.

 

[paws]

Is it possible to use retro68 to compile a library and then link to it from Codewarrior? I like actually using my Mac to code.

 

[uyjulian]

You can use a ssh client on your Mac if you like coding on your Mac. This allows you to use e.g. retro68 and nano from your Mac.

SSHeven: a modern SSH client for Mac OS 7/8/9

I think the cat is out of the bag on this one, so here's a thread announcing my SSH client (beta release): SSHeven is a bare-bones open source SSH client with support for the latest protocol version and encryption standards, allowing access to the default configurations of all modern servers...

68kmla.org

 

[halkyardo]

To be useful, it would need the driver part, mbedtls changes to use it, and new applications that need the speed, and also would only be useful to people with the hardware. All doable, but the vintage mac software development ecosystem is so small, it would be a shame to ask you to do the work with such a small chance/amount of payoff.

Yeah, it's undeniably a bit of a pipedream, but would be cool nonetheless. I doubt I'd ever get around to implementing a TLS library or an application for it myself, but I guess where I'm at is, if someone wants to try it out, I'll gladly add support to the driver (I might do it anyway if I get the time - the crypto engine seems to be a bit awkward to use, but not devastatingly so) and contribute a card or two to test with.

 

[cluster_fsck]

I extremely strongly recommend retro68 instead of vintage compilers if you want to use modern OSS libraries. A basic build of mbedtls was mostly tricky cmake/config setup instead of a completely intractable missing headers and missing compiler feature slog.

I could give some pointers if you're interested. Libraries that don't use posix features or directly do I/O are relatively easy to use, and good libraries meant for embedded systems are careful to be extremely portable.


To be useful, it would need the driver part, mbedtls changes to use it, and new applications that need the speed, and also would only be useful to people with the hardware. All doable, but the vintage mac software development ecosystem is so small, it would be a shame to ask you to do the work with such a small chance/amount of payoff.

I would be interested to see if a 68040 can do TLS unaccelerated. I think it's only like a weekend of messing around, I may try to make a little proof of concept program.

Oh yeah, I plan on using retro68 to get all the libs built. I'm actually having trouble getting it to compile properly on Mac OS X Tiger 10.4.11 on my PowerBook G4/500, but will spend some time trying to debug it this weekend. I don't have the compile error handy, but it was an issue with resolving some symbols in libboost and I'm thinking the version that Tiger brew installed may not be compatible.

Love that this thread is getting some action, especially as we celebrate the Mac's 40th birthday

 

[halkyardo]

Oh yeah, I plan on using retro68 to get all the libs built. I'm actually having trouble getting it to compile properly on Mac OS X Tiger 10.4.11 on my PowerBook G4/500, but will spend some time trying to debug it this weekend. I don't have the compile error handy, but it was an issue with resolving some symbols in libboost and I'm thinking the version that Tiger brew installed may not be compatible.

Love that this thread is getting some action, especially as we celebrate the Mac's 40th birthday

I use Retro68 too and I ran into similar issues on my PowerMac G4 running 10.4.11, but did eventualy get it working. If I remember right, I needed a newer version of gcc than Apple shipped (that bit was described in the README, but it's easy to miss), and then had to change a couple of things in Retro68's tools because they were using bleeding-edge C++ features that the compiler still didn't support. Meant to submit an issue for it but never got around to it. My main recollection from the experience was multi-day compile times!

Since then, retro68 has moved to a new GCC version entirely, so things could well be different now, but might be worth reaching out on github; Wolfgang is pretty responsive and pleasant to deal with, and from what I understand, it's still his intent to support hosting Retro68 on older systems.

 

[cluster_fsck]

I use Retro68 too and I ran into similar issues on my PowerMac G4 running 10.4.11, but did eventualy get it working. If I remember right, I needed a newer version of gcc than Apple shipped (that bit was described in the README, but it's easy to miss), and then had to change a couple of things in Retro68's tools because they were using bleeding-edge C++ features that the compiler still didn't support. Meant to submit an issue for it but never got around to it. My main recollection from the experience was multi-day compile times!

Since then, retro68 has moved to a new GCC version entirely, so things could well be different now, but might be worth reaching out on github; Wolfgang is pretty responsive and pleasant to deal with, and from what I understand, it's still his intent to support hosting Retro68 on older systems.

I think the issues are a me problem -- I had gcc 7.5.0 from Tiger brew installed but never updated the path to the compilers when setting the gcc options for Retro68 build

It's building now and hopefully will finish without issue and I can get my entire build toolchain in order. There's a couple of small bugs in ssheven running on Mac OS 9 that I want to see if I can address as a test of the overall build system. I also wanted to add Keychain support in my fork of it...