SecureSockets

SecureSockets has Zero Page issues. According to posts on comp.sys.acorn.apps, “the original programmer is long gone”. Another post suggests that the module should be part of the OS. It is one of the parts of !Hermes (part of NetFetch) and so throws up loads of errors in the Zero Pain log files every time one fetches email. It’s a right pain. :-((
Apparently, Alan Wrigley has produced a new version of !Hermes that has fixed ZPP issues apart from within SecureSockets.
Can something be done to produce a new ZPP-free version?

Dave: This is discussed frequently. The normal conclusion is that a SecureSockets alike module needs written. No one has yet volunteered to write it!

The normal conclusion is that a SecureSockets alike module needs written. No one has yet volunteered to write it!

Comment on the news groups is to the effect that Andrew “doesn’t regard it” (the source) “as commercially sensitive”.
So the question is why not just drop it into the ROOL archive and let people play?

Sorry. I was thinking of Justin Fletcher’s EasySockets. Do they have any overlap?

I think EasySockets provided a module giving an easy way to make socket connections (i.e. TCP/IP-based communications as used on the internet). Socket programming is fairly straightforward from C, but Justin’s module made it nicer from BASIC.

SecureSockets, on the other hand, is a module to provide SSL (also known as TLS), which is the security layer used for encrypting communications across the internet. This is much more complicated, as it requires providing implementations of several different enciphering algorithms as well as verification of certificates.

It would be updated, almost undoubtedly, by porting OpenSSL or a similar library, but converting this into a module would be a challenge. The source code to the current version would show how it was done before, but clearly it wasn’t totally well-written if it suffers from ZPP issues, and OpenSSL will have changed so much since SecureSockets was last worked on that it could be a big job.

So, should there be a bounty for a new SecureSockets?

No, there should be something that binds to the OpenSSL (or mbedTLS) shared library and provides the SecureSockets API.

TLS is security-critical, and libraries like OpenSSL have security vulnerabilities reported regularly. It is critical that the solution is easy to update to the latest version of the library; you simply cannot trust your connections are secure otherwise.

The sorry state of SecureSockets is that someone 16 years ago took OpenSSL and did major brain surgery to turn it into a module. This brain surgery was very invasive, which is why nobody has attempted it since – it would need doing again for every upstream release. SecureSockets thus remains 16 years old, and contains hundreds of known vulnerabilities . To make it even worse, it runs in supervisor mode – ie there is no protection whatever between this vulnerable code and anything in your system.

Meanwhile, we can build OpenSSL and mbedTLS as shared libraries in a regular, automated, fashion. A new vulnerability is disclosed, a new library build comes out the door (with a click of a button currently). The only remaining problem is that applications that use the SecureSockets API don’t use them – which is why I suggest writing a shim to convert from one to the other. This is not completely straightforward because SecureSockets is a SWI API and the shared library runs in user mode – however it’s the only maintainable way out of this mess.

SecureSockets thus remains 16 years old, and contains hundreds of known vulnerabilities .

And a big problem: it is not compatible any more with most SSL / TLS software, for example SSH servers.

So, should there be a bounty for a new SecureSockets?

If a bounty is interested people paying money to make something happen, could the same result be achieved when interested people pay money to buy upgrades from rcomp – capitalism!

We have released the source code to SecureSockets at http://www.armini.co.uk/SSLsource.zip It has been available for some time.

Whilst not defending the age of SecureSockets, looking at the vulnerabilities in OpenSSL, many came in after the version of OpenSSL used in SecureSockets. So, AFAIK the module was not affected by the likes of HeartBleed.

The API is included in the zip.

AFAIK, it is all presented as separate code, so really a lot of what Theo says isn’t entirely accurate. The API is separate to the OpenSSL stuff. Tom Hughes updated it to StubsG in the 2000s without (AFAIK) any major effort. However, it does need Acorn’s inetlibzm which I believe has proven tricky to find for people who tried it since.

The only reason we haven’t done more with it is that the quotes for progress on the module have exceeded the possible income from updating it. For example, NetFetch 4 upgrades have yielded less income then a significant SecureSockets update would cost. This is also true of ZPP generally, incidentally. We’ve spent about 10x (honestly) more money on ZPP than we’ve earned, which is why we may seem a bit sluggish at times, especially when none of the computers or support schemes we offer need ZPP or other updates.

I think it is also worth mentioning why I disagree with Theo’s comments quite strongly.

Many RISC OS programmers use the Acorn/ROOL C compiler tools. These do not use shared libraries, but instead compile in functionality to the main program. The only way (that I’m aware) for such programs to have “shared” functionality is via !System modules (ie. standard relocatable modules), which is what SecureSockets is. The module provides very similar calls to standard socket SWIs (which programmers will already be using for insecure TCP/IP code), such that modification to use SSL can be achieved by simply using the secure swis rather than the insecure ones. We have had positive feedback on this API and approach from programmers. Furthermore (perhaps even more significantly) it can be used from BASIC too.

Expecting all RISC OS coders doing TCP/IP coding to move to GCC/shared libraries is, I feel, unhelpful. It’s certainly a viable option, but you’re effectively saying that BASIC/ROOL C tools are unfit for network coding. That seems a very “un-RISC OS” thing to do/say. I know GCC has its merits, and for ported software, it is definately “top dog”, but I think programmers should have a choice in what they use (just like they do in everything else in RISC OS) rather than dictating the use of something (shared libraries) which only apply to GCC and aren’t even part of the standard OS/Disc build. This is RISC OS, not Linux.

Small “PS”… if it were possible to have RISC OS modules interfacing with shared libraries, then yes, that would be a fantastic solution. However, I’ve not seen anything to suggest this is (currently) possible. Please prove me wrong, as this would allow a “Secure-Sockets”-style module to provide the programmer API to Norcroft C/BASIC whilst utilising GCC shared-library versions of cryptlib/openSSL.

Hear! Hear!

We have released the source code to SecureSockets […] However, it does need Acorn’s inetlibzm which I believe has proven tricky to find for people who tried it since.

I don’t think that can be a barrier – it’s right there in Lib/TCPIPLibs/o/inetlibzm in the DDE26 install, and also DDE25. I’m too lazy to go check earlier backups.

The TCPIPLibs comprise inetlib, socklib, socklib5, and unixlib, plus their “zm” counterparts for building into modules. There’s 2300 lines of programmer notes in LibraryDoc in the same directory to supplement the overview in PRM 5a.

Andrew: you want secure software. So you have to use an always current version of OpenSSL. So you either have to update the SecureSockets module, or use shared libraries, or statically link to a library and release always a new version of the software using it. There is no other way.

Now you have explained that updating SecureSockets to a state where it is really secure (i.e. up-to-date with the current OpenSSL incarnation) is too expensive. Keeping it up-to-date is even more expensive. You have also explained that not everyone wants to use GCC. Fine with me. But what is your suggestion that results in an inexpensive way to keep the software secure if you also don’t agree with Theo???

you want secure software. So you have to use an always current version of OpenSSL

That’s debatable. There’s a new flaw in OpenSSL – even has a cute name and logo.

The number of rather dumb flaws turning up in recent times makes me wonder if there’s an alternative that isn’t OpenSSL…

However, it does need Acorn’s inetlibzm which I believe has proven tricky to find for people who tried it since.

? More info? My module uses this for its sockets things, haven’t experienced any problems (yet!) (that haven’t been limitations in the Internet module or API itself).

Well surely it wouldn’t be too hard to make a wrapper module to load the GCC module and provide a SecureSockets SWI interface?

The number of rather dumb flaws turning up in recent times makes me wonder if there’s an alternative that isn’t OpenSSL…

There are many alternatives. Some good, some not so good. Some easy to port, some not so easy to port.

I’ve never looked at the SecureSockets API, but I’d hope that it wouldn’t be too hard to switch over to a different backend library.

Steffen – hence why I made the source code available last year (or even 2014) at the URL mentioned in my post. Since that open sources both the API and the current module code, it is the best that I can do without pouring money into a black hole.

When I looked into it a while back (viewing the reported version/flaws on the OpenSSL site), older OpenSSL versions (ie. 0.9 era) seemed to have fewer reported flaws than some of the more recent versions, possibly because they were smaller/simpler, but I don’t know. That’s not meant as a “let’s ignore newer OpenSSL” argument, but more just an observation. As I say, it meant that SecureSockets wasn’t affected by some of the more high-profile issues/flaws. And, contrary to what was suggested in another posting, the module seems to still work with the SSL/TLS servers we’ve seen in the wild for email/https purposes. As such, an updated version of what’s there, compiled with current tools and made ZPP/ARMv8-safe wouldn’t be a horrendous first step.

Then folks can look at what needs doing to incorporate a new OpenSSL build. I’m not sure it is as modified as Theo suggested – Dave included most of the changes he made in the “Dave Says” documentary files. IIRC his biggest problem was getting it to compile in 1990s era C tools. ISTR he had to use GCC to compile one object file, then munge it into the rest of the Norcroft-compiled code. This was because (at the time) GCC couldn’t do modules.

Could someone who knows GCC currently please confirm/deny my assumption/guess that modules (ie. providing SWI-based APIs) can’t utilise shared libraries.

Quick lay-person’s explanation of SecureSockets API and what the module does…

Normally for TCP/IP programming you’ll create a “socket” and read/write/listen for data on it. The SecureSockets module provides a very similar API, but handles all the encryption automatically. Thus a programmer can continue to use socket-style swis/coding just as for non-encrypted TCP/IP programming, without having to worry about the encryption/ssl side of things.

We originally paid a four-figure sum (I forget how much in the end) for its development to allow https: transfers in WXL. Subsequently, we provided the module to other folks and it has been used in a number of other R-Comp and non-R-Comp products over the years, where encrypted TCP/IP transfers were needed.

Andrew, I agree a lot with what you say, and I’m not blaming you for the current state of SecureSockets. Nobody has enough time in this market to achieve what they would like. For you time=money, but it’s the same problem. This is my major point in this discussion: it is not worth wasting time doing something repeatedly (eg manually porting the latest version of OpenSSL every time one is released). It’s not wasted time as such: there is nobody to do it, it simply won’t happen. The process has to be automated to have any chance of happening at all.

Small “PS”… if it were possible to have RISC OS modules interfacing with shared libraries, then yes, that would be a fantastic solution. However, I’ve not seen anything to suggest this is (currently) possible. Please prove me wrong, as this would allow a “Secure-Sockets”-style module to provide the programmer API to Norcroft C/BASIC whilst utilising GCC shared-library versions of cryptlib/openSSL.

That’s exactly what I’m suggesting. A module that implements the SecureSockets API that is capable of interfacing with the shared library. The more general case of attaching to a shared library over some kind of user-space binding (eg from BASIC) is actually easier because you don’t have to mediate that with the SWI interface, it would just be a function call into the library directly.

The point is that, by solving the general case, you can also solve the specific case with the existing parts we already have. As usual time is always the major constraint (and such a project is un-funded in time until someone volunteers) – what I’m suggesting is to make more efficient use of that time.

(I should mention we already have mbedTLS as well as OpenSSL built – though I have no experience with mbedTLS)

PS: I haven’t done a thorough audit of the OpenSSL vulnerabilities to see if they apply to SecureSockets because that’s nontrivial work – the OpenSSL CVE database only goes back to 2002. A skim of the Securesockets code (thanks, hadn’t seen that was available) suggests it’s from SSLeay (OpenSSL’s precursor, 1998-ish). The bottom line is that the best way to stay secure is to stay updated, and being ‘too old to be vulnerable’ may buy you a little on the swings but is pretty risky on the roundabouts.

Edit: cross-posted with Andrew’s recent couple of comments, not digested them yet

Theo, I’d absolutely support that (even finacially) if such a thing were do-able, but I’ve not seen any example of a module using shared-libraries, so my natural assumption is “not do-able right now”. It’s be pretty cool if it were :)

However, that sounds like a not-inconsiderable project. I worry that a larger project might take longer than just a ZPP/recompile of the sources I released last year, which might provide a stepping stone until something better is available. I’m happy to contribute the existing SecureSockets API/code as the basis of something newer/better, esp if backwards compatibility is possible API-wise.

As long as the end result benefits all RISC OS coders, at this point, I’d be a happy bunny.

And, contrary to what was suggested in another posting, the module seems to still work with the SSL/TLS servers we’ve seen in the wild for email/https purposes.

It does no longer work with any of the major German email providers.

It does no longer work with any of the major German email providers.

I think part of the ‘fix’ of the most recent OpenSSL mess was killing off SSLv2 for good. Maybe this has affected the capabilities of the module?

I am no security expert, but the deprecation of SSL up to v3 had nothing to do with buggy implementations, but with attacks on the various ciphers.

SSLv3 had various ciphers available like RC2, DES, RC4, 3DES and AES. Some were broken, some had insufficient key size. No trustworthy cipher remained. So it has been deprecated, I think in 2014 already.

I’d be careful of such broad statements. I can’t speak for all German ISPs, but it worked for at least one German customer recently. It also works fine with gmail still (or did last time I tested – last month I think). I’m not saying everything is hunkydory, but painting pictures like this helps no-one.

SecureSockets has its faults (hence why I’d like to see it updated), but configured correctly with a semi-current version of NetFetch/Hermes, it will fetch/send emails in most cases. We also run (free to customers) SMTP servers to help anyone with an insurmountable problem.