TCP/IP bounty beta release

With ref to ‘SecureSockets’ module – how far did anyone get to updating it?

Some seemed keen to find some ‘C’ software to update.

ie – like some very old text editors :-)

Whilst I don’t want to go off topic too much (this is the AcornSSL thread), we have source for SecureSockets 1.03 (32bit) but not the 1.04 StubsG build. Frustratingly, that 1.04 is better all round (it works for secure IMAP, for example, whereas 1.03 doesn’t seem to). I think 1.04 was done by Tom Hughes, but when I last asked (a while ago) he couldn’t find the code and had packed away his RISC OS kit.

The current 1.05 release is binary modded 1.04 to fix a significant zero-page issue that prevented it working on 5.24 (thanks Jeffrey!).

The stated reason for this not being an option is to ensure “RISC OS is properly secure and compliant with certificates”.

Well, if that’s really ROOL’s reason, then I’m sorry ROOL, but you’re completely off the mark. It’s simply not up to the module to make that decision. That’s the calling program’s job.

to ensure “RISC OS is properly secure

Uh huh…

Unfortunately, it is probably significantly more code in AcornSSL, as really this needs to be offered on a per-application basis, to avoid you accepting a certificate in one program and inadvertantly affecting another.

Why so much complication? Shouldn’t it suffice to set an option on a per-socket basis, like:

• Ask the user (as now)
• Always accept
• Always reject
  ?

Then the program can decide what can happen. If it is known that something is using potentially incorrect certificates, the program can say “as long as there’s something, just accept it” or “bail if anything looks wrong” or the default current behaviour.

I notice nobody has responded to my previous question – does the module pass back status that the user is being prompted? Because, you know, timeouts… It would be dumb to timeout a connection because the user is reading what to do.

The stated reason for this not being an option is to ensure “RISC OS is properly secure and compliant with certificates”.

Well, if that’s really ROOL’s reason, then I’m sorry ROOL, but you’re completely off the mark. It’s simply not up to the module to make that decision. That’s the calling program’s job.

Agreed.

Unfortunately, it is probably significantly more code in AcornSSL, as really this needs to be offered on a per-application basis, to avoid you accepting a certificate in one program and inadvertantly affecting another.

Why so much complication? Shouldn’t it suffice to set an option on a per-socket basis …

Or implement my original proposal, which is to allow a custom callback to be associated with a socket. That way it’ll allow programs which want to provide their own UI to do so (“generic toolbox dialogue box” and “generic VDU text prompt” sound a bit limiting), as well as allow non-interactive programs to implement whatever logic they deem to be appropriate.

If ROOL don’t budge, the only outcome will be that people will use alternate solutions – maybe continue to use existing creaky old modules like SecureSockets, or maybe create a new SSL module, or maybe embed the SSL library straight into each app, or work out ways of fooling AcornSSL into thinking that a user is present. Neither of which are likely to be what ROOL intended when they first created the bounty.

Because, you know, timeouts… It would be dumb to timeout a connection because the user is reading what to do.

Dumb. Yes. It is.
I just ran another test and after waiting for a little over 30 seconds the module task’s window closes and the module returns with the error I mentioned earlier: Handshake error in state 9,984.

Timeout.

Good f*cking grief.

Well, at least I can now proceed with the AntiSpam implementation, as you can simply ignore the bloody stupid query window and assume failure. It’s not as good as being able to accept as well, but at least the whole run doesn’t grind to a halt.

Hi all. Lots of heated debate here, which I suppose is what a beta phase is all about. There’s also some misinformation which suggests ROOL isn’t listening. As ever, the opposite is true. Here’s what we’re proposing to do in the next iteration:

• When a user first accepts/rejects a cert, that choice is remembered for the duration of the session (until next reboot)
• If a user has a particular cert they want to always accept (e.g. self-signed), there will be a place to put the CA for it (e.g. somewhere in !Boot)
• We’ll add an interface to AcornSSL so applications can ask that bad certs are automatically rejected with the handshake error

If this doesn’t address all of the issues that have been discussed here, I would be very interested to understand the specific use case.

Also, as a reminder, there’s the tcpip@ email address listed in the ReadMe which most of the people on this forum thread haven’t emailed to. If you want to talk directly with the bounty claimant to address specific issues, then it’d be a very good idea to get in touch there.

To me, the last line in the AcornSSL ReadMe/txt didn’t suggest the e-mail address should be used in preference.

If this doesn’t address all of the issues that have been discussed here, I would be very interested to understand the specific use case.

The options suggested should work for me, but I’m not sure limiting the first one to the current session is a good idea. Having to make that choice again after reboot is not how clients on other OSs handle it.

Hi all. Lots of heated debate here, which I suppose is what a beta phase is all about.

At least discussion is taking place.

I just wish I understood it all and could contribute .

Recent changes to CVS seems to be showing a new root CA data file at 12:50 today … but it seems to me to have no changes, & is still v4.3 dated June 20.

which most of the people on this forum thread haven’t emailed to.

Come, now, Steve. Surely you’ve been here long enough to know it is more gratifying to whinge on a forum. If nothing else, it can invoke a confirmation bias when others say “me too” or aid in doing the right thing when somebody says “oh good, not like that, do this”.

There’s also some misinformation which suggests ROOL isn’t listening.

I don’t think it’s that anybody thinks you aren’t listening, I think with a big important project like this it is easy to lose sight of one person working on the project so updates won’t turn up every single day. We’re just impatient, that’s all. ;-)

Though, an admission of mine, I have a largish (niche) project coming along. Well it’s coming along, but it’s been coming along since early 2014. I work on it from time to time, but it still isn’t finished. When will it be? I want it ready now but in reality it’ll probably be another four years…

May I suggest adding an option to accept bad certs as well? That’ll cover both eventualities, and save the hassles of mucking around with locally held certs.

Justification for “accept all” – these are the mail setup choices for Android (8?) email client:

That’s not a justification – that’s a security hole! :) Don’t start me on the five whys here, but I would ask “why is this really needed?”.

To be more clear; if the application is claiming to use TLS and then deciding to allow any old shite through as a cert, then the user is being mislead and they cannot trust the connection or, by extension, the application. For us to encourage (facilitate) this sort of behaviour from applications, when the very point of this bounty is to improve Internet security in RISC OS, I’d like to hear some real world examples of when this is absolutely required vs the three suggestions I already listed above. I’ve not heard one yet. Give me a compelling use case and I’m sure we can support this behaviour.

May I suggest adding an option to accept bad certs as well? That’ll cover both eventualities, and save the hassles of mucking around with locally held certs.

I dunno for bad certificates, but an option to accept an expired certificate is certainly a must. I can even remember the number of times at work when using remote desktop connections I got popups signalling expired certificates and asking me if I still really want to connect to the remote machine. It we actually be pretty annoying not to have access since these remote machines are our only access to the machines on which we host web applications for our customers.

Or implement my original proposal, which is to allow a custom callback to be associated with a socket.

Please correct me if I’m wrong, but that would rule out its use by BASIC apps because you can’t have callbacks.

How about adding some return error codes (or one code and several subcodes) to report certificate errors? I appreciate that a 30 second timeout might not be appropriate in those cases. Is 30 seconds an arbitrary choice? Could it be made longer in the case of certificate errors? Could it be user-specified?

To me, the last line in the AcornSSL ReadMe/txt didn’t suggest the e-mail address should be used in preference.

Earlier, when I suggested you try to explain the previous problem you had with needing the pointless double connect() to that address, which subsequently appeared in the next beta change logs, I assumed you had got in touch. If not, it turns out ROOL are not only patient listeners who tolerate people swearing at them for their efforts, but have excellent long distance psychic powers too.

I dunno for bad certificates, but an option to accept an expired certificate is certainly a must.

That already exists, and has since TCP-IP_Beta1, perhaps you’ve not had chance to try the module yet? You get a dialogue warning that the connection is untrustworthy, but which you can accept and connect anyway. Today’s proposal extends that by not asking every time (which could get tedious).

It we actually be pretty annoying not to have access since these remote machines are our only access to the machines on which we host web applications for our customers.

I’m a little worried that your customers have remotely connected machines on the public internet, running applications, but that don’t have valid certificates. Eek. Take a look at LetsEncrypt – they give out free (valid) certificates for everyone.

I think Steve’s suggestions are really helpful, but still don’t quite accommodate all the situations. Please note, my only wish here is to make AcornSSL as good as possible – we’re working hard to get rid of SecureSockets wherever possible (it’s costing me a pretty penny, too!).

It would be exceedingly helpful if the module provided a way of adding the certificate as an “always OK” thing, rather than it only lasting for the session.

Example…. User fetches email every 30 mins unattended, every day. Do we want him to have to manually accept the certificate each day the first time (or when he reboots in between)? Of course not. The first time he fetches (ever), yes, that’s fine, but day-to-day, once he’s approved it, just get on with it :) (If he’s clicked “always accept”).

User almost certainly doesn’t know where the cert is stored, nor how to put it there. So, expecting him to manually add certs is really a no go. If the module provided an option to add permanently, then problem is solved.

Also, I tend to agree with Jeffrey, Rick and Frank – it might be a security hole, but an application really should have control over whether the module throws a hissy fit or not. You cannot, for example, expect embedded-type use to accept a system which needs user-intervention every time a cert changes (which the embedded supplier may have no control over).

Imagine, if you will, a system deployed in a business situation (ie. in the field), where the OS isn’t visible. It is securely connecting to a remote server. When the system is deployed, you could (if you had to) manually add a cert to the store. After a while, though, the remote server might well change the cert in some way. That then won’t be in the store, and suddenly the embedded system stops working. That’s not acceptable (and is, more or less, a real-world example that happened a month or two ago).

Solution is basically to have a mode/state where an application receives warnings about certs but can continue. That way it can be down to the program to deal with problems (eg. emailing/contacting admin/developers to warn about a problem), whilst failing gracefully.

Otherwise, you end up with a system that is only useful in a particular subset of uses (ie. when user is present).

Important thing to remember – the vast majority of people have no clue what a certificate is, or what to do with it, or even that it exists. Expecting them to manually handle them is really a non-starter.

Also important thing – you (end user) cannot tell a service provider what to do. Just because we’d like every supplier to have perfect certs that are always current, the fact of life is that this is often not the case. We (end users) may not even have control over certs on our own servers if they are handled by a 3rd party hosting service (cough 1&1, cough).

Just to be clear, I’m 100% in agreement that we need to take certs seriously, but I think we also need to be realistic that in many cases there may be cert issues. Sometimes that will matter, sometimes it won’t. Sometimes a user will be present, sometimes they won’t. For AcornSSL to really cut the mustard, it needs to accommodate all these situations depending on the type of usage situation.

Steve – real world usage scenario:

You have a system involving a custom-written client application of your own design (perhaps unmonitored) and a server (for argument, we’ll say also of your own design).

You deploy it with correct certificates. The system is essentially a closed loop – the client app provides front end in the field. The server (being of your own design) is running on your servers. You control both ends, but prefer to encrypt data in between. (We’ll use medical records by way of example).

You have a problem with certs a year down the line (maybe something expires, maybe there’s a cock up of some sorts).

KEY FACT – the system is still secure. The only thing that’s wrong is that there’s been an admin cock-up at the server end (or 1&1 haven’t done what they said they would).

As proposed, this still secure system will fail until everything is neatly resolved. But if it happens at 12 midnight, it might take until 10 or 11am to resolve. Which, since (hypothetically) this system is being used half way round the world, is an entire business day of failure.

Oops.

(Also, and you’ll appreciate this as a programmer, it makes the system developers look like complete numpties whilst its “down”, which is never what you want your users to see).

I suppose the counter-argument is how to differentiate this scenario with one where a “fake” system is interjected between the client and server. But even in this case, the application can choose how to represent that (eg. merely change a UI element, or fail hard, or anything in between).

Additional “real world” example of when things go wrong – I’m told by an “Apple Bod” that if there’s ever a cert oddity (eg. server changes) with email on Apple phones, the mail client appears to “lose” all the email. There is no “auto-correction” until the user recreates the mail account at which point they can re-accept the cert. You can imagine the irate support calls an ISP might get in such situations. (note – this is a second-hand report, so may have a level of chinese whispers). Let’s try and avoid such issues on RISC OS!

PS, taking the Android screenshot as an example… Steve, you’re right, it is a security hole. But only if the user chooses to do so. Unless you’re in a George Orwell novel, you probably should have the freedom to make that choice! (And, let’s be brutally honest, do any of us really care about the certs for our email accounts, as long as our email works?). [evil smiley!]

Extra thought – I think there may also be a bit of a confusion between ROOL and the user-base as to what “improving SSL/TLS security on RISC OS” means.

What we (R-Comp and ROD) were hoping for is a replacement for existing solutions that implemented modern encryption protocols, and could be easily maintained. Thus RISC OS would be compatible with the latest SSL/TLS levels that might be encountered in the real world.

Steve’s comments suggest that ROOL see an additional step to actually enforce things to ensure secure behaviours on the part of users and applications.

RISC OS hasn’t historically been a “thou shalt do it this way, and no other” type of OS, so this extra step is perhaps a little uncomfortable for us all. I can see the desire to drag us kicking-and-screaming out of the dark ages (!) but please don’t go further than other OSs in the pursuit of this.

Slightly “political” example – it’s like saying “we let far too many immigrants into the country… so…. let’s build a wall and stop all of ’em”. I think a better response would be “so… let’s improve border checkpoints to know (and control) who’s coming in and why) so that we can make informed decisions”. OK, my example kinda petered out under its own politics there, but hopefully my meaning comes across.

An example of my own is that I’ve written an app that turns lights on and off based on a timer. It does this by talking to a Philips Hue bridge. Currently I’m using the Hue’s HTTP API, but Philips is recommending that HTTPS be used instead and has hinted that a future update may remove HTTP support¹.

Being a small “embedded” device, the Hue bridge uses a self-signed certificate and there is no facility for changing this to a “real” one. At present I can’t fire off any timers using HTTPS because the confirmation pops up; if I’m not at the computer then the Hue API never receives the request.

The example given above of adding the CA to !Boot may be an acceptable workaround. Next time there’s an update I’ll need to see whether the CA details change. But in any case, as this is a “private” app running on my own network it would be nice if I could just say “I don’t care that this isn’t a trusted issuer”.

That’s just my NZ$0.02 :P

¹ “For compatibility purposes we will maintain the HTTP version of the local API by default for a period of at least 1 year. When out of beta we recommend all developers to move their apps to use this new endpoint as soon as possible.”

It would be nice if there were some info on how the ‘Certs’ system works.

I notice there are several ‘CertData’ files around with different names in !Boot.

It would be nice if there was only one to update – and simple download from the ROOL site.

Some examples of the files:-

“<Sargasso$Dir>.cabundle
“InetDBase:CertData” AcornSSL
“NetSurf:Resources.ca-bundle
!CaCertificates.ca-certificates/crt !Otter-browser ?

Not sure about SecureSockets – could be embedded in the Module?

Does RO FireFox have one?

It would be nice if there was only one to update

The problem is that because SSL isn’t built into the system, various software products implemented their own SSL methods, which explains why there are multiple piles of certificates. I can’t imagine this will change in a hurry, however if the format of a CAbundle is standardised (no idea, never looked) then maybe we could try to convince everybody to look in the same place for them, so at least there will be only one to keep up to date…

The question boils down to a very basic decision: should AcornSSL be just a thin wrapper for a modern SSL/TLS library, or should it be an OS component handling all possible aspects of encrypted connections for all clients from a humble BASIC script to a full-blown application?

Security is always relative. E.g. how is the certificate storage protected, i.e. how can we make sure that nobody tangles with its content? If we can’t, the result can never be considered “secure” from the point of view of a modern OS. In an OS that is completely insecure from the start like RISC OS it is hard to say where to start and where to stop. Personally, I would prefer a “management application” for the secure storage that can make connections to any secure target and let the user examine the certificate and let the user decide whether to add it to his personal certificate storage or not. Then, the low level connections from AcornSSL would just check against all certificates and OK those with a valid one and deny those where there is no accepted certificate.