AcornSSL server functionality

In any case you are not going to have many instances of server sockets like you are client sockets in a browser

I pointed NetSurf at news.bbc.co.uk with ResRec open, and saw about a dozen sockets opened simultaneously on port 443 of an Akamai address serving up the BBC’s stuff. The same experiment with riscosopen.org.uk opened up 5 sockets on port 443 at ROOL’s web server.

aren’t the certs already loaded by acornssl good enough

Server certs are completely different from those in InetDBase:CertData and refer to your own domain that you’re serving up, plus of course a path to a root CA.

I’d love to see your code to see how you have done this

I’ll happily send you my source code, when I’ve got the wheels back on, and my test code too.

But you can’t have my certs or private key – not that they would do you any good anyway. If you want to test this you’ll have to get your own domain, because server certs have to match the domain they’re serving up.

This may be a good point at which to remind all potential testers that you’ll have to get your own domain and set of certs. You can get both for free. I use No-IP.com for my free domain, and Let’s Encrypt is the go-to for free cert+key sets. Access to a Linux box is extremely handy for this. (I don’t know if it can be done from a Raspberry Pi running Linux – I’d be interested to hear.)

I’m getting error 76 from my test server when I point NetSurf at it, although Firefox is happy. PRM 5a-382 says error 76 is “Not a data message”. Does anyone know what that means?

The same experiment with riscosopen.org.uk opened up 5 sockets on port 443 at ROOL’s web server.

Yes but there is only 1 server socket listening for connections, If the server socket creates the mbedtls_x509_crt from a filename passed in AcornSSL_Creat it could pass it on to the ssl_handles returned by accept.

Could I create a certificate for localhost to test with? I have a demonstration program for normal sockets which puts a server in one taskwindow and client in another an you can type between the windows. Could I do a similar thing with Secure sockets by creating some sort of local cert?

There is a feature you can turn on, as a user option, that enables a primary choice of HTTPS, but even that offers to connect on the HTTP port after a delay.

I was concerned because I saw a post saying it would become the standard setting in a future version, and the event isn’t until October.

I also saw a post saying it didn’t apply when on a LAN.

I was concerned because I saw a post saying it would become the standard setting in a future version, and the event isn’t until October.

It almost certainly will – eventually. It’s not shown in the roadmap I’ve seen, so it’s a distant future on current info.

I also saw a post saying it didn’t apply when on a LAN.

I recall that statement, but I’ve been able to reproduce when on the same network segment, across network segments and on a home network, so that doesn’t seem to be true.
Still, it’s not a default setting even on Firefox which tends to be a little further down the track than other browsers.

I’ve been struggling and making no progress for a few hours now, until…

When I pointed Firefox on my Linux box at my DDNS address, it worked fine. When I pointed NetSurf on my RasPi at my DDNS address, the test server always failed with error 76 when trying to do the AcornSSL_Recv. I ran Wiresalmon on the RasPi and got mightily confused when I saw everything twice, but that turned out to be that I was seeing it go out to the SmartHub and come in from the SmartHub. D’oh.

Finally I ran NetSurf on a different machine, and it worked fine.

Only a small sample is involved so far. Anyway, it looks like I should get used to using different machines for client and server.

Maybe your router is like mine and messes up a machine talking to itself using the domain name?

I added heyrick.ddns.net into my Hosts file as an alias for 127.0.0.1 and that works fine.

I added heyrick.ddns.net into my Hosts file

Very good – now off you go to Let’s Encrypt to get yourself some certs and a key!

I added heyrick.ddns.net into my Hosts file as an alias for 127.0.0.1 and that works fine.

Certificates for the FQDN will only work for the host with that name – normally looked up by DNS. If you check your machines name server entry “testpc1” you get the IP of the interface that communicated with the DNS.
If you want to connect locally then you are on the loopback / localhost interface and need 127.0.0.1

If you enter 127.0.0.1 in the browser then on HTTP it works, on an HTTPS connection the response and behaviour of the browser is rather dependent on the content of the “alternate names” section of the certificate. If that doesn’t include 127.0.0.1 then it ain’t happy.

Unexpected finding: I wanted to check that a chain of certs can be loaded individually. However, loading just the first of the two certs was enough to keep Firefox happy.

The second on its own didn’t work, unsurprisingly.

Of course, if one cert on its own works, I cannot find out if loading the two separately works.

I’ve been testing my stuff. I made a self-signed certificate/key pair with the same “Common name” as my ddns domain name. Firefox put up its “dire warning” page and issued an SSL fatal alert to my server, but didn’t give up. I restarted my server and told FF to go ahead; it’s been happy to accept it since then.

If it hasn’t given up, and is waiting for the user to decide whether to go ahead, that sounds like a bug in Firefox to me – there’s an error, but it’s not fatal, is it?

Anyway, since subsequent attempts worked, I guess that’s good enough.

“Common name” as my ddns domain name.

Exact FQDN?

I restarted my server and told FF to go ahead;

Told it to record an exception, so

it’s been happy to accept it since then.

Because there’s a recorded exception – have a look in Firefox > Tools > Options > “Privacy and Security” > Manage Exceptions

Not there yet. I think you’re getting close though.

Anyway, since subsequent attempts worked, I guess that’s good enough.

I have a client/server demo which is written using mbedtls working if it is any use – this is just basic communication between 2 taskwindows.

If the server socket creates the mbedtls_x509_crt from a filename passed in AcornSSL_Creat it could pass it on to the ssl_handles returned by accept.

Ignoring the return values and error checking, AcornSSL_Certify() does this:

_kernel_oserror *api_certify (int *han, int *servcrt, int *pkey, int *r0)
{
 mbedtls_ssl_conf_own_cert (&h->conf, (mbedtls_x509_crt *) servcrt, (mbedtls_pk_context *) pkey);
 mbedtls_ssl_setup (&h->ssl, &h->conf);
}

Please have a look at the docs for the second call. The warnings are enough to put me off trying.

It would be nice to roll Certify, Accept and Handshake into one, but then you’d have to retain state over multiple calls for non-blocking operations – it’s very likely that, in the context of a web server, the client will attempt to open numerous connections so quickly that they would be unable to handshake simultaneously without maintaining state. It looks to me like the adverse consequences of the simplification outweigh the gains.

Speaking of socket handles, and the Internet Event, and Socketwatch: is there any reason why we shouldn’t define AcornSSL_Create to also return the socket number in R1? At present its only return value is the SSL handle in R0. I can’t see a compatibility issue if we were to add extra returned value.

In theory this would remove the need for an AcornSSL_GetSocket SWI.

To save looking it up, the Internet Event (19) is mostly triggered when a socket has received data, so it allows sockets to be read without polling.

What do you think?

Yes it seems reasonable if anyone used acornssl_createsession they would know the socket so they wouldn’t need to read it.

I’ve been looking at mbedtls and it’s a shame acornssl was done the way it was it seems to me it could have been so much easier.

All that was needed for sockets was

int ssl_session_create(sock, config); //error returned or 0
void ssl_session_destroy(sock);
int ssl_recv(sock, buf, len, flags)
int ssl_send(sock, buf, len, flags)

other functions would be needed to create a custom ssl config

You write your standard socket client/server and after connect/accept call ssl_session_create then use ssl_recv/ssl_send where you use send/recv. If the socket passed to ssl_send/ssl_recv hasn’t been set by ssl_session_create they default to the normal send/recv.

The problem then becomes setting up config

You could start with a default client config and default server config and add functions for custom configs or to modify the defaults. So ssl_create session could be just

ssl_session_create(sock, SSL_DEFAULT_CLIENT_CONFIG)

or something more complicated where you create a custom config beforehand. Socketwatch would work exactly the same because you are working with sockets not an abstracted handle.

Re: SocketWatch

SocketWatch v0.07 (download from ) included some notes about use with AcornSSL, and a fix for handling errors better if an SSL socket is wrongly used. The notes include:

SocketWatch should only be used with the normal socket numbers, not the ssl socket handles used by AcornSSL.
However, it can be used for secure sockets with a sequence like:
Socket_Create to get socket normal socket descriptor
AcornSSL_CreateSession to get ssl socket
SocketWatch_Register of normal socket descriptor

During AcornSSL beta testing I queried the lack of visibility of the ‘normal’ socket number from AcornSSL, and was told the SSL ‘socket number’ would remain ‘opaque’ as documented.

I also wrote a small StrongHelp manual for AcornSSL, which is available from my website Corrections or additions welcome!

the SSL ‘socket number’ would remain ‘opaque’ as documented.

In that case the proper way to do it is with AcornSSL_CreateSession so I would concentrate on modifying that instead of AcornSSL_Creat

All that was needed for sockets was

Just been looking at how I used AcornSSL in FTPc and I’ve used it similar scheme to this calling AcornSSL_CreateSession after connect. I did want to repeatedly call AcornSSL_CreateSession in a non blocking fashion until the handshake was complete (like you can with connect) so that I knew at that point that the handshake was successful or not but it doesn’t do that and you have to deal with continuing after ENOTCON in recv/send replies – don’t like it it seems wrong.

Anyway getting back to modifying AcornSSL for servers I think the most useful change to AcornSSL_CreateSession would be to add an option for it to take a mbedtls_ssl_config handle as an argument and add functions to create it. That may add flexibility without modifying AcornSSL

I don’t think it is a good idea to use mbedtls_net_bind for AcornSSL_Bind because AcornSSL_Connect works like connect so AcornSSL_Bind should work like bind also mbedtls_net_bind and mbedtls_net_connect don’t work with dot number addresses. The more I look at this the more I’m convinced that AcornSSL_CreateSession is the way to go as then you can stick with standard socket layer handling of everything except send and recv and don’t have to be concerned about the AcornSSL implementation of other functions.

Please have a look at the docs for the second call. The warnings are enough to put me off trying.

Yes it appears each socket needs its own config and you can’t avoid the ssl_setup call. That is ok you can still share preloaded certs you could do something like

/*
 * first call *certp = NULL
 * subsequent calls uses the certp returned from first call
 * Reason codes: SSL_CERT_FILE, filename, 0
 *               SSL_CERT_BUFFER, buffer, buffer_len
 *               SSL_CERT_DEFAULT_CLIENT, 0, 0
 *               
 */
_kernel_oserror* ssl_cert_parse(cert_t** certp, int reason, const void* ptr, size_t size);
void ssl_cert_destroy(cert_t*);

That allows you to create a certificate chain from various sources. You can do a similar thing for keys. Obviously ideally we just use the mbedtls library but we are not so we have to be selective in what is implemented with a view to expansion later.

Then you add a config object

#define CONFIG_TYPE_DEFAULT_CLIENT
#define CONFIG_TYPE_DEFAULT_SERVER
_kernel_oserror* ssl_config_create(int type, config_t** out);
void ssl_config_free(config_t*);

you can create a basic config which you can alter with

SSL_CONF_OWN_CERT
SSL_CONF_CA_CHAIN
ssl_config(config_t*, int reason, r2, r3, r4);

More reason codes than you need can be added later.

Colin, I have two questions for you:

1) Naive question – I don’t understand the protocol. You’ve defined two flags or operation codes, CreateSession_New and CreateSession_ReuseAuth, but you’ve only used them in AcornSSL_CreateSession. Could they also work in AcornSSL_Creat?

2) For creating a session, the docs and comments say the top 24 bits of R0 are flags, but I remember you suggested using them as function codes. Are you sure that’s a good idea? I’m not. If the 24 bits are a function code, we have over 16 million codes available – a ludicrously high number – and they cannot be used simultaneously. If the 24 bits are flags, we can flag 23 things, either individually or simultaneously, leaving 1 bit for a flags extension mechanism. I think even 23 things are far higher than are ever likely to be used. I’d vote for leaving them as flags. What are your thoughts? This one is rather important right now as I want to add another bit or code. Right now, the two you added could be defined either way without loss of compatibility.

I had clearly misunderstood some of the code. In the light of my better understanding, the second question above is daft, and I withdraw it.

Question 1 still stands, though.

I’ve also had a rather belated realisation that, since the new SSL session handle that I want to create doesn’t have a socket, it makes more sense to modify AcornSSL_CreateSession to do what I want, so I’ve just written and tested a version with AcornSSL_Creat back to exactly the way it was, and adding reason code 2 to AcornSSL_CreateSession to create an SSL server session without a socket.

I’ve got some tidying up to do, and another check that it still works despite the tidying up; then I’ll post an update for people to try. The docs are updated too.

There’s an updated version of the AcornSSL module with server functionality, and the associated documentation of the extensions to its API, on my web site at https://davehigton.me.uk/Progs/AcornSSLServer.zip

That is to say, it’s there at the moment. At some point I’ll take it down, either because my changes have gone into the official version of the module available from this site, or because no-one has shown any interest in it.

Please, please, anyone who has any interest in it: take it, try it, break it, and above all comment on my proposed extensions to the API.