How feasible is TLS under System 6?

[Tekk]

I want to make a Facebook IM client for System 6. Facebook's chat API is simple enough, but it requires a TLS-encrypted HTTPS connection to retrieve the authentication token.

I'm up to the challenge of implementing cryptographic algorithms, but according to this IANA page, there are....a lot... of algorithms used with TLS.

I'm sure that there are a few 'cipher suites' that are commonly used, and the rest are obscure, but I'm not sure how to find out what these are, and I don't know how mathematically taxing the algorithms are on a 68k processor.

Does anyone have any statistics on the most commonly used cipher suites?

After implementation, I will need to integrate my TLS code with MacTCP somehow. I wonder if they implemented any "connection filter" functionality that I can redirect streams through.

 

[cb88]

Why not just make a generic XMPP/Jabber client first and then extend it to support TLS. So you don't bite off so much at once.

Dunno why you would have to integrate anything with MacTCP... TLS wouldn't have anthing to do with the transport later other than sitting on top of it? Or perhaps I am missing something.

I'm thinking (HTTP -> TLS) -> TCP or does TLS require closer integration with TCP than I am thinking?

If you make your app GPL you may be able to just use MatrixSSL as its quite small. I'm not a GPL propoent per say I'm acutally lean MIT/BSD... but its there and might save you headache.

 

[cb88]

check this out also.. http://strophe.im/libstrophe/ Its a small C XMPP library.

I had intended to get it working on my sparcstation. I did get the demo working though ... its probably a good C code base to start from.

 

[uniserver]

a facebook IM client for system 6/7 would be pretty sweet.

 

[IPalindromeI]

+1 for generic XMPP. If you could do it, maybe even support OTR for cryptography! (have fun on a 68000)

 

[Bunsen]

Crypto would be a perfect use for the DSP in an AV Quadra, or on a Nubus card, if only low-level access to them wasn't so darn near impossible.

Tekk, there is another thread around discussing similar projects; I'll see if I can dig it up.

Thread: Where are all the programmers?

About halfway down page 3:

I have been developing web (js/RoR) and iOS applications for the last few years and now I start to get interested in system 7 C++ development. /

I am thinking about connected applications such as a twitter client, gmail client, or a cool control panel like a dock to replace the default mac launcher. In fact, I think that plenty of small iOS/mobile applications could be made for system 7.

/ETA/ This may be useful: https://sites.google.com/site/chuzzum/

 

[Cory5412]

One thing that may be possible (maybe even a very good idea) if you're interested in learning programming/networking on the old system and on a new system is to do the core of the client on a modern system like Linux/BSD/OSX/Windows and then have that computer communicate (in completely clear text, possibly using something like the IRC protocol) to the 68k Mac.

The things I would look at for examples of this are bitlbee, which does literally this thing (it is an xmpp/aim/msnm client that runs an IRC server that you can connect to in plain text), but it actually acts as an IRC server and Quassel, which has the "core" and "client" aspects.

This gives you more horsepower for the network and encryption bits of your application while letting you create a native Mac ssw6/ssw7 graphical experience on the client end, and also prevents network traffic from needing to go to the 68k Mac directly.

 

[Tekk]

Why not just make a generic XMPP/Jabber client first and then extend it to support TLS. So you don't bite off so much at once.
Dunno why you would have to integrate anything with MacTCP... TLS wouldn't have anthing to do with the transport later other than sitting on top of it? Or perhaps I am missing something.

I'm thinking (HTTP -> TLS) -> TCP or does TLS require closer integration with TCP than I am thinking?

If you make your app GPL you may be able to just use MatrixSSL as its quite small. I'm not a GPL propoent per say I'm acutally lean MIT/BSD... but its there and might save you headache.

These are all really good ideas. You're right about TLS not requiring as close integration with TCP as I originally thought. Making my app GPL doesn't bother me too much, so I'll probably just use MatrixSSL to save myself the trouble. Some programmers enjoy implementing everything from scratch (which is perfectly fine), but I'm more concerned with the end result.

check this out also.. http://strophe.im/libstrophe/ Its a small C XMPP library.
I had intended to get it working on my sparcstation. I did get the demo working though ... its probably a good C code base to start from.

I've downloaded it and am looking through it now.

One thing that may be possible (maybe even a very good idea) if you're interested in learning programming/networking on the old system and on a new system is to do the core of the client on a modern system like Linux/BSD/OSX/Windows and then have that computer communicate (in completely clear text, possibly using something like the IRC protocol) to the 68k Mac.
The things I would look at for examples of this are bitlbee, which does literally this thing (it is an xmpp/aim/msnm client that runs an IRC server that you can connect to in plain text), but it actually acts as an IRC server and Quassel, which has the "core" and "client" aspects.

This gives you more horsepower for the network and encryption bits of your application while letting you create a native Mac ssw6/ssw7 graphical experience on the client end, and also prevents network traffic from needing to go to the 68k Mac directly.

This would certainly speed the program up, but relying on a modern computer for core, end-user application functionality kind of takes the fun out of the project for me. I want to do something that makes 68k Macs a little bit more practical on the modern Internet.

I do, however, plan on doing some development on a modern machine, until I have MatrixSSL/Strophe/Expat figured out. I also have to wait for my SCSI cable to arrive, so I can load MPW onto my SE/30.

The first step on the Mac end will be getting the libraries to build. After this I can implement a text-based generic XMPP client. We'll see where it goes from there.

 

[TylerEss]

One thing that comes to mind as a gotcha is that you don't have access to UNIX-style sockets under MacTCP. I would assume that most SSL / TLS libraries you find are written for a system with UNIX-style sockets.

The "GUSI" (Grand Unified Sockets Interface) library exists, and claims to give you something close enough to UNIX sockets under both MacTCP and native OpenTransport. Your mileage may vary.

It might end up easier to implement your own SSL / TLS directly on top of MacTCP streams.

 

[Tekk]

Looking at the MatrixSSL API, it appears that all you need to do is pass buffers filled with data you want to encode/decode. It doesn't seem to be specific to any one system of sockets.

Granted, I haven't looked at MacTCP yet, so I don't know if any unexpected wrenches will be thrown into the works.

 

[Tekk]

Well, I now have the libstrophe XMPP library connecting to FB chat non-securely and returning my friends list. I was wrong about them requiring a secure connection, but I still want to implement security anyway.

libstrophe contains tls_openssl.c and tls_gnutls.c, so they already have the TLS stuff abstracted out into modules depending on what SSL library you're using. I guess the next step is to write a tls_matrixssl.c. This isn't too bad so far, but I haven't touched my Mac yet. :beige:

 

[cb88]

axtls is BSD licensed ... not as many features as matrixSSL but sounds easy to use. It also sounds more server oriented so might not be of use.

http://axtls.sourceforge.net/

and polarSSL https://polarssl.org/ ... sounds quite similar to martixSSL in most every way.

 

[Tekk]

Finally got some time to work on this... after fighting MacTCP for an hour (device manager calls? really?) it looks up addresses.. and then crashes.

Not pictured: my super cool empty friends list window (it's hidden behind the "console" window)

Enough work for tonight!

 

[NJRoadfan]

Ah the joys of programming on an OS without memory protection. One thing you may want to keep in mind is that most folks may not be running MultiFinder on System 6 or System 7. A Desk Accessory version may be a good idea, but I don't know if Toolbox APIs can maintain an online state if the DA is inactive, like when you launch a program.

 

[markyb86]

There used to be an app "bomb catcher" or something like that

I don't know the exact name, but it let you recover from bombs without restarting.

 

[cb88]

So... How is your TCP/IP connection setup? Sounds like you may be using localtalk? Hmm... looks like it crashes just after doing a dns query perhaps? I was reading about bbraun's http disk block driver... and he said that dns occurs in the device driver which is bad so you may want to try hardcoding a server address just to avoid doing DNS. I don't have any mac I can develop on yet sadly.... working on it!

This looks like it has useful info http://www.umich.edu/~archive/mac/misc/documentation/mactcpinfo1.2.txt

Also I like XMacPP ;-) ... lol Better than MacinJabber which would sort of be a play on MacinTalk!

 

[Tekk]

There used to be an app "bomb catcher" or something like thatI don't know the exact name, but it let you recover from bombs without restarting.

Yeah, I just need to get it together and learn how to use a debugger.

So... How is your TCP/IP connection setup? Sounds like you may be using localtalk? Hmm... looks like it crashes just after doing a dns query perhaps? I was reading about bbraun's http disk block driver... and he said that dns occurs in the device driver which is bad so you may want to try hardcoding a server address just to avoid doing DNS. I don't have any mac I can develop on yet sadly.... working on it!
This looks like it has useful info http://www.umich.edu/~archive/mac/misc/documentation/mactcpinfo1.2.txt

Also I like XMacPP ;-) ... lol Better than MacinJabber which would sort of be a play on MacinTalk!

My SE/30 is running Open Transport's MacTCP emulation on System 7.5.5 through a PDS Ethernet adapter. I believe the reason it was crashing is because I was printf'ing the IP address from within a Device Manager callback, which are run on the interrupt level and are extremely sketchy about memory allocation and register use according to Inside Macintosh. I assume a complex function call like printf screwed up some of the registers which were required to be preserved. Anyway, I now just save the IP in the callback and print it in my normal application code, and it works fine.

I now have the app sending and receiving data, but it appears FB has changed their service slightly, and now requires a secure connection to use the DIGEST-MD5 authentication scheme.

The current step is getting PolarSSL to compile on THINK C, which isn't that bad, except that THINK doesn't seem to find header files in subdirectories, so I have to painstakingly go through each of PolarSSL's .c files and change #include "polarssl/xxxxx.h" to #include "xxxxx.h". xx(

 

[cb88]

From what I've been reading recently thinkc is pretty suboptimal as well... I imagine you'd be better off with CodeWarrior if you could find a copy which I believe has a built in debugger.

Also I have no idea if this is feasible.. but aim for something with elliptic encryption algorithms as diffie-hellman is busted and thus worthless security wise...

 

[Tekk]

I'm testing out CodeWarrior, and while it's definitely better than THINK, it has the exact same problem #including files in subdirectories! No big deal though, I've written a Java utility to correct the #include directives as well as change the line endings to Mac format, and I'm about to run it now.