SecureSockets Bounty

Another question: does StubsG have any relevance these days?

The old library code (libcrypto and libssl) that I’m linking with has file dates back in 2000, so I assume it’s entirely possible that it isn’t 32-bit compatible

Yes, it would almost certainly be those libraries.

Another question: does StubsG have any relevance these days?

Kinda.

• ROOL provide softload versions of CLib for RISC OS 3.1 and later (3.1 being the earliest version of the OS that ROOL support at all)
• However users might appreciate not needing to update to newer CLib versions if they’re currently using an old one (or if they’re using software which doesn’t work on new versions – like the sscanf (?) bug that nobbled TechWriter when it got fixed)
• But, on the other hand, SecureSockets needs to be secure, so it’s important to make sure that it uses library functions that are bug-free. So it’s probably better to require that people use it with recent versions of CLib rather than buggy old versions.

Humbly suggest that you leave StubsG until all is running ok.

With ref to the 32bit issue – test the files in ‘o’ dir – with !ARMalyser.
It may be – as a temp measure – on a 32bit machine to hand 32bit those files.
How big are they?

How are you planning to test the Module?

How are you planning to test the Module?

I’m open to suggestions from anyone who knows anything about SSL/TLS – and I don’t!

All I have at the moment is a noddy little pair of test apps (server and client) that run in task windows. They currently rely on a certificate/key file that is provided with the source but whose certificates expired around 2001. Fortunately at the moment, from my POV, the module doesn’t check for certificate validity, so it happily accepts them and the apps connect and transfer data.

Other than that, all I have is things like NetSurf and MPro.

How big are they?

libcrypto is 745976 bytes, libssl is 183100 bytes. The names and headers suggest they they are AIF libraries. Again, not a topic I know much about.

I don’t know how to recreate these libraries. The crypto folder contains 1328 files, the majority of which are source and header files.

Humbly suggest that you leave StubsG until all is running ok.

Humbly suggest that everything 26 bit related is well down the list of importance.
Since a standard CLib solution with bug fixes would be the offering for all new (32 bit) systems then building one version means so much less testing.

In general the only real reason for a StubsG version is to keep the “I’m not going to use a ‘Castle’ Clib crowd” and they wouldn’t want to use a ‘Castle’ Secure Sockets module anyway

I don’t know how to recreate these libraries. The crypto folder contains 1328 files, the majority of which are source and header files.

Take a look at the end of ArmSSL.DaveSays:

--libcrypto--
5) Some directories just have a few .o files, so just use c <filename> to make them
 others have makeall/makeme/makedir scripts to take the effort out of it.

6) Compile all the dirs listed in libraries
7) Copy the objects into 'libs' and link them all into 'libcrypto'
---libssl--
8) link the stuff in ssl into libssl
--api--
9) compile the code and the header.
10) link the code, the header, libssl, libcrypto, socketlibzm, inetlibzm, unixlibzm, stubs together
11) volia, one securesockets module :)

p.s. look out for more DaveSays files in the source... :)

For libssl it looks like you’re lucky enough to have a script to compile the files into object form (ArmSS.ssl.MakeDir, which relies on the ‘c’ macro set up by ArmSSL.Macro). But I can’t see anything obvious for linking them into a library – possibly the ‘lib’ target of Makefile/ssl will work.

For libcrypto it looks like there are indeed several different scripts littered around the place for building individual directories, so it looks like that one’s going to be a fair bit more hassle.

Considering how much of a pain it’s going to be to get libcrypto and libssl rebuilt, it’s probably not worth the effort. Just concentrate on getting a new library (mbedTLS, modern OpenSSL, whatever) hooked up instead (and with proper makefiles, not some unmaintanable crap).

Look at ArmSSL.API.c.code. That 300 line C file is the entireity of the module frontend. It contains 21 SWIs, most of which just make a single call directly to OpenSSL. If you can get mbedTLS building, it should be trivial to convert the frontend to use it. If you’re unsure what a particular OpenSSL function does or what its mbedTLS equivalent is, Google is your friend.

Considering how much of a pain it’s going to be to get libcrypto and libssl rebuilt, it’s probably not worth the effort. Just concentrate on getting a new library (mbedTLS, modern OpenSSL, whatever) hooked up instead

Interesting idea, thank you, Jeffrey: that an “all or nothing” approach might actually be simpler than an incremental one.

I won’t be in a position to try it until early next week though.

I’m open to suggestions from anyone who knows anything about SSL/TLS – and I don’t!

mbedTLS has a test suite

For functional test, you probably want a server doing TLS. If you have a Raspberry Pi you aren’t using, I’d suggest setting up Raspbian, nginx and Let’s Encrypt, which gives you a valid certificate if you can make it accessible from the Internet (eg forward ports on your router). There’s a variety of tutorials: the best one I found happens to be in German but the list of commands should still work!
If Let’s Encrypt doesn’t work for you (because you can’t expose the Pi, for instance) you can use a self-signed certificate instead. Don’t forget that the ‘new’ SecureSockets should complain about a self-signed cert and prompt the user if they really want to continue.

OpenSSL has a command line tool openssl which can do key operations and s_client and s_server to handle sockets..

Once you have the basics working there are third-party TLS test suites out there, for instance tlsfuzzer

Because most of these are expecting to run on Linux, you’ll probably have to forward ports over to the Pi/another Linux system.

Is there a document somewhere that gives an overview of all the transactions that take place when a secure connection is set up? I’ve so far failed to find one that has enough detail and not too much!

I think I must be a step forward. I’ve used the zerossl tools to get certificates and a private key from Let’s Encrypt that are accepted by the existing server test app. However, the client’s state remains at 0×1120; if the connection were successful, it should go to 3. So the client test app isn’t happy, and of course I’ve no idea why.

I’ve got too many unknowns here. It reminds me of the development we used to do years ago. You don’t want to be trying to bring up untested software on untested hardware – when it goes wrong, you have a very difficult job diagnosing what’s at fault.

I tried the server test app with Firefox and the new certs/key. Originally FF complained of “… uses an invalid security certificate. The certificate is only valid for davehigton.me.uk Error code: SSL_ERROR_BAD_CERT_DOMAIN” I had a rare flash of inspiration and realised that this was because I was giving FF the url http://192.168.16.69 which is nothing to do with davehigton.me.uk. The fix was to add an entry to the /etc/hosts file so now I can point FF at my domain. I just have to remember to remove the entry when I want to point FF at my real web site…

OK, the bad domain error no longer occurs, but the test app seems to see an incoming string 1 character long consisting of the letter G. Strange. Also the test app seems to go into a place from which Esc cannot stop it (it’s a BASIC app in a task window). I assume that’s a blocking call somewhere.

A business RISC OS user has asked for a more secure way to upload file to a webserver than !FTP. There seems to be a number of options discussed in this thread. What can be achieved currently that is suitable for an average user to use?
He is willing to pay a couple of hundred pounds towards achieving this!
I wonder if this could be used to kick start a bounty.

sftp.

SiteMatch and puttytools package will help here.
Even if I would like other solutions (CloudFS/!FTP) to be able to do this too.

For my sub-domains, I configured a shell-less SSH access.
No access to shell from SSH, SFTP only and no access to the whole filesystem (root is fixed to the user’s home directory).
Perfectly secured. And opened to third party users.

Where’s the money? :)

Thanks David
I’ll point the customer at those programs. I wonder that with SiteMatch whilst offering more than !FTP he might miss the option to just drag and drop one or two files.
On the other hand I suspect he wouldn’t want to use command line utility!
I see puttytools inc. psftp comes from Theo it talks of psftp is that effectively the same as sftp? The pages google turns up confuse me!
It is a 2004 version:-(

psftp is that effectively the same as sftp?

Yes. psftp is a command line client for the sftp protocol.
While old, it works with my up-to-date server.
It would be cool to see !FTPc working with ftp, ftps and sftp.

I’ve just been messing about with some noddy little test apps in BASIC to give me some familiarity with using the secure sockets module, at least.

Looking at the API, I don’t see any method to check the validity of a certificate. I’m aware that the present version accepts expired certificates without protest. I’m sure that checking a certificate is something that we would want in the module rather than make each client app provide its own code.

So, when a client connects to a server, at what stage should the check be made? What are the possible errors (e.g. expired, cross site) to search for? Should there be a priority of errors? Is it sensible to let the client proceed if the certificate is in error? (I suspect yes – Firefox allows the user to continue.)

So, when a client connects to a server, at what stage should the check be made?

During the SSL/TLS protocol negotiation phase.

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10660_.htm

Step 3 is where the client verifies the server’s certificate. However, I’m not quite sure where this fits into OpenSSL.

If OpenSSL was sensible, it would happen as part of SSL_connect, with the function returning an error if the certificate is invalid. But the sample code on this page checks the certificate verification result manually using SSL_get_verify_result, so maybe with OpenSSL checking the verification result is always a manual process? (and does that also suggest that the connection will still be made, even if the certificate is invalid?)

Also that sample code uses BIO_new_ssl_connect instead of SSL_connect – I don’t know enough about OpenSSL to be able to say why.

Should there be a priority of errors?

I’d say it should return a list of errors (OpenSSL’s online manual suggests that it has an error queue, which presumably contains the results of any certificate verification errors, but the docs are a bit pants and there’s no clear place where the queue or the error codes are described)

This page may also be of interest.

Over the last couple of evenings I’ve been havig a very frustrating time trying and failing to build even the simplest code to use OpenSSL. Because the libraries come from the riscos.info site, I’ve been using GCC.

First question is why GCC’s object file from the compiler is typed as Text, when it’s actually ELF. Anyway…

I’ve got libssl_1/0/2k-3 and libssl-dev/1/0/2k-3. The latter contains the header files within an h directory in the !LibSSL app. But the h files require to be in a directory called openssl – so why does !LibSSL contain an ELF “App” called openssl? This guarantees that the structure as provided cannot be used. I have had to rename the ELF, create a directory called openssl, and move the h directory into it. OK, at least I can get my three lines of code (just the initialisers for libcrypto and libssl) to compile.

Now, what am I supposed to link this against? It wants a symbol ERR_load_crypto_strings. Am I suppsed to find this in libcrypto/a (which is typed Text, though clearly mainly a binary file), or in libcrypto/so/1/0/2 – and, if the latter, should one of the symlinks work as a library name on the command line to “ld”?

I’ve tried all the versions of arguments to -L (for the path to includes/libraries) and -l (to name the specific library) that I can think of, but ld always claims to be unable to find the library. So am I specifying the library and path-to-library incorrectly, or am I specifying something that is not an appropriate target to link against?

My 0.02

But the h files require to be in a directory called openssl – so why does !LibSSL contain an ELF “App” called openssl? This guarantees that the structure as provided cannot be used.

Yeah, that sounds like a mistake in the autobuilder package configuration.

I’ve tried all the versions of arguments to -L (for the path to includes/libraries) and -l (to name the specific library) that I can think of, but ld always claims to be unable to find the library. So am I specifying the library and path-to-library incorrectly, or am I specifying something that is not an appropriate target to link against?

When you specify a library name using -l you need to omit the ‘lib’ prefix and ‘.a’ suffix. I.e. -lcrypto -lssl

When setting the library path using -L you’ll want to point to specify the folder containing the .a file. I’d assume GCC will be happy with using a RISC OS format path for that, but I’m not sure.

My 0.02

LibreSSL is all but light and easy to port.

I just tried the mbedTLS last CI build from riscos.info and found that even the first line of some tutorial example code failed to compile.

It turns out that the source used by Jenkins is woefully out of date – it actually is a version of PolarSSL, which is the predecessor to mbedTLS.

If Theo or anyone else associated with riscos.info is reading: are there any plans to update mbedTLS on riscos.info?

And another thing: I read from tls.mbed.org that mbed TLS 1.3 has been declared end of life, and no further maintenance releases are planned. The announcement I’m reading is dated 2018 February 5.

Thanks to a prod from Dave, I’ve updated the riscos.info autobuilder script to use the master branch from github, rather than the fixed tarball releases. The only difficult bit was extracting the version number from the sources to put on the package.

It’s now built v2.7.0 – for some reason 2.8.0 (which was released last week) is only on the development branch. Current build here – completely untested:
https://ci.riscos.info/job/packages/job/mbedtls/

Let me know if there’s any issues.

Thanks, Theo. I feel some more experimentation coming on in the next few days!