TCP/IP bounty beta release

Re my previous post about SocketWatch v0.06: the reason that my AcornSSL_Ioctl failed when setting FIOASYNC was a stupid error on my part. I am still trying to change my application and SocketWatch so they will work with both SSL and non-SSL sockets.

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.

The application servers and front-ends are isolated in distinct LANs for each customer and accessible on the public side through specific system of routers , firewalls and load-balancers and on the developer side through a single PC server with access strictly restricted to the developers of those applications and its just the certificate used for the RDP by that PC server that is often left expired till the administrator of that machine as nothing better to do. Nothing insecure since its all internal and it would be really problematic if the connection were to be refused for such a reason. As it is it is just annoying as RDP tends to forget you told him not to ask again for confirmation that we still want to access the PC server.

I appreciate this is mostly a philosophical debate. There are people saying something is “secure” because it’s ‘internal’ or ‘closed-loop’. There are others, me included, who would argue that the environmental security or otherwise has nothing to do with the security that TLS is aimed at providing. The debate is fruitless because we’re comparing apples and oranges. AcornSSL is trying to provide a system service to ensure network connections are secure and ensuring the user is in the loop when nefarious events are detected that may compromise their security. If software authors want to ignore that facility and trust that their setup is secure, such that they are no longer able to spot a rogue employee man-in-the-middling their supposedly secure system, then so be it. RISC OS has a proud history of arming developers with foot guns.

With that in mind, here’s the updated proposal:

• When a bad cert is detected, the dialogue that opens will have a new “Accept always” option which persists the decision to accept that particular cert now and in future, regardless of reboots
  • In the background, AcornSSL will update the stored exceptions list – users don’t need to know about or touch this
• Before making a connection, applications can make use of a new interface in AcornSSL through which they can ask that a connection fails immediately if the cert is faulty (without opening the dialogue box) or continues without error if the cert is faulty for any of a set of possible reasons (e.g. allow if self-signed but not if expired, etc.)

The default will, of course, be to alert the user to dodgy certs and not to blindly wave them past. But application authors will be able to relax this checking by degrees, to the point of allowing any old junk through.

In future, we may add logging to help users spot any applications that decide to allow faulty certs through.

When a bad cert is detected,

Define a “bad certificate” because a self signed certificate, to quote one example spoken of above, is not a ‘bad’ certificate but is a certificate for which the root CA may not be known by the client system.
Equally a certificate generated in our enterprise CA is not bad but has an unknown root CA if seen outside our organisation.
In things like RADIUS auth a self-signed is not only common but recommended. The aim there is to stop connections unless the users have the required certificate.

I think the updated proposal will satisfy peoples requirements for unknown root CA situations.

I normally take a “bad certificate” to be one where the name in the certificate does not match the name of the transmitting host or the expiry date has passed. In those circumstances I’d expect the setup to flag the situation every time without possibility of saved override.

We (at work) see various large organisations ignoring name match and expiry quite regularly and since the proxy blocks such things we merely send a notification to the host organisation that their site is “broken”. Any expectation that we will lower security by allowing such brokenness to “just work” is given all due consideration.

I mean ‘bad’ in the sense of ‘untrusted’. That’s AcornSSL’s view of the world.

With that in mind, here’s the updated proposal:

Thanks. That looks like what we need.

I mean ‘bad’ in the sense of ‘untrusted’.

Ah, but as Steve was pointing out – “untrusted” due to self signed (hence no chain of trust) is a different matter to “untrusted” due to expired, root CA revoked, or pointing to an entirely different domain.

Self signed on an internal setup is no big deal if you know why – my printer’s WiFi connection uses self signed HTTPS.
A bad cert on a public website could be a bigger deal.

We’re getting there, but there are degrees of untrusted.

RISC OS has a proud history of arming developers with foot guns.

(^_^)

We are indeed debating the irrelevant. I am simply interested in ensuring this bounty is delivered in a way that meets with what the community needs and with the goals we set out to achieve.

In future, we may add logging to help users spot any applications that decide to allow faulty certs through.

Definitely.

There may be a Wimp component in there to handle the pop up dialogue (I’ve not seen it, is it an error box or something fancier?), so if this is the case then may I suggest plonking a bloody great red ! icon on the iconbar to list the recent connections handwaving bad certs through? If an application needs to do this, it should be done with the user being informed, so when the big scary icon pops up they will know what it is relating to.

In the background, AcornSSL will update the stored exceptions list – users don’t need to know about or touch this

…unless they wish to revoke the “accept always and forever” permission?

With that in mind, here’s the updated proposal:

And thats how mission creep stops things being released, though in this case I think the debate has been good even though it would of been better if somethings were sent back earlier.

Talking of mission creep then Rick’s suggestion for a revoke option is a good one for those “Oh sxxx, what did I just do” moments and the log seems sensible as how do we know what corners developer A cuts and doesn’t tell us about our compromised security.

Though thinking about it as a RISC OS user we can’t be that concerned by it given the crudy old security we have used to date.

There may be a Wimp component in there to handle the pop up dialogue (I’ve not seen it, is it an error box or something fancier?)

It looks like this:

When a bad cert is detected, the dialogue that opens will have a new “Accept always” option which persists the decision to accept that particular cert now and in future, regardless of reboots

Thank you; just what I needed in my case :)

We are indeed debating the irrelevant.

I was simply pointing out that in these descriptions “bad” because it’s wrong (expired or mismatched with host) is different to “untrusted” because the root CA or the certificate itself is unknown.
In situations like this clarity is essential.

I still hear people debating semantics of the word ‘bad’. Any objections to the proposal? The person working on this bounty, for a fixed amount of minimum-wage, is understandably uncomfortable with the scope creep and I’m going to draw a line under this. Going once, going twice…

Perhaps we should set out the reasons why a certificate should be questioned or rejected.

- Mismatch with host
- Expired
- Self signed
- Defective? can’t be read or understood in some way
- anything else?

And what exactly do we want to do – every time, first time, subsequent times – for each case.

I’m worried by the idea of the module putting up a dialogue box when it needs to question the cert, because that takes control away from the calling app. I don’t see the approach as being applicable under all circumstances. I would rather see the error being passed back to the app for it to handle.

Hi Dave – re-read the latest proposal. There’s no user-facing dialogue if the application decides to override the default behaviour (the dialogue box) for a given connection by using the proposed new interface.

Perhaps we should set out the reasons why a certificate should be questioned or rejected.

- Mismatch with host
- Expired
- Self signed
- Defective? can’t be read or understood in some way
- anything else?

1. Mismatch with host = question every time, arguably reject
2. Expired = question every time, arguably reject
3. Self signed = question first time and allow persistent accept
4. Defective? can’t be read or understood in some way = reject

Which I suspect may be the coded behaviour

- anything else?

Off the top of my head:

• The certificate validity has expired.
• The certificate has been revoked (is on a Certificate Revocation List).
• The certificate Common Name (CN) does not match with the expected CN.
• The certificate is not correctly signed by the trusted CA.
• The CRL is not correctly signed by the trusted CA.
• The CRL is expired.
• Certificate was missing.
• Certificate verification was skipped.
• Other reason.
• The certificate validity starts in the future.
• The CRL is from the future.
• Usage does not match the keyUsage extension.
• Usage does not match the extendedKeyUsage extension.
• Usage does not match the nsCertType extension.
• The certificate is signed with an unacceptable hash.
• The certificate is signed with an unacceptable PK alg (eg RSA vs ECDSA).
• The certificate is signed with an unacceptable key (eg bad curve, RSA too short).
• The CRL is signed with an unacceptable hash.
• The CRL is signed with an unacceptable PK alg (eg RSA vs ECDSA).
• The CRL is signed with an unacceptable key (eg bad curve, RSA too short).

OK, OK, I cheated and looked at the list.

I’m worried by the idea of the module putting up a dialogue box when it needs to question the cert, because that takes control away from the calling app. I don’t see the approach as being applicable under all circumstances. I would rather see the error being passed back to the app for it to handle.

If anything, I’d be more worried that by suggesting to pass back 20 different errors that’s then requiring every application to duplicate some logic to check all the cases, and any that might be added in future, and get that logic right. By having the logic held in one place, any mistakes can be fixed once and all applications benefit.

Your application might only have caught 4/20 (20%) of possible reasons to reject.

Hmm…

There’s also some misinformation which suggests ROOL isn’t listening. […] We are indeed debating the irrelevant. […] and I’m going to draw a line under this.

I understand that mission creep is a bad thing, and the person doing the work isn’t going to want to do loads of stuff that was not part of “the original spec”. That’s perfectly understandable; however what is clear from this discussion debate of the seemingly irrelevant ☺ is that what AcornSSL is trying to do, and what the end users of it want it to be able to do are slightly different.

The problem as I see it, is that the module is trying to be a “jack of all trades” for SSL connections. In effect, apart from some minor variations in behaviour, it is basically “sockets with added SSL”. To that end, is it even possible for the application using AcornSSL to know what sort of encryption is in use?
It’s a rhetoric question because I know the answer, and I also know that in 99% of cases the specifics of the underlying methods used are irrelevant. You ask it to make a “secure” connection to this specific server, and it goes ahead and does so. How, what, where, why are not the concern of the application. In principle there’s nothing wrong with this.

Unfortunately there are as many broken, incomplete, and half-assed SSL implementations as there are broken, incomplete, and half-assed websites. I’ve already pointed out all of my “smart” printers that offer HTTPS for admin but use a self-signed certificate (makes one wonder why they bother?), and others have pointed out other use cases for SSL in cases where there is no effective chain of trust to support the certificate in use.

With this in mind, and the things that may work in the background, potentially on autonomous systems (translation: no user to respond to questions), it is clear that popping up a UI to ask every single time is a non-starter. Two points are clear to me:

• There needs to be a way of having the program be able to tell AcornSSL how to behave
• There needs to be a way of AcornSSL reporting a failure reason, because “certificate is bad” is far too broad to be useful. Remember we are talking about SSL. ALL certificates are bad unless they can be shown to be trustworthy. There are myriad reasons, some are show stoppers, some are not. Categorising all non-good as simply “bad” is about as logical as categorising all blondes as dumb…

If anything, I’d be more worried that by suggesting to pass back 20 different errors that’s then requiring every application to duplicate some logic to check all the cases

With this in mind, and noting Sprow’s comments, there should be three behaviours:

• Default – exactly as it is now, the module will pop up a UI asking what to do
• Always reject – and AcornSSL passes back a code to say why the connection was rejected
• Always accept – and it behaves as if all was okay (and any lack of “secure” is the onus of the application)

Sprow’s comments regarding catching only a subset of possible reasons is not necessarily correct. You see, the behaviour can be programmed as follows:

Open socket to remote server with "Always reject"
It fails.
Why? Is this a reason we can accept?
  If so, retry connection with "Always accept"

There is no reason to have a huge switch statement for dealing with all of the conditions. For example Usage does not match the nsCertType extension – I don’t even know what that means, and if I did there’s exactly sod all that the application can do to fix it.
However, some of the reasons (The certificate validity has expired – hello Orange, are you listening!?!?) and whatever appears on self-certs can be handled as known behaviours. If the behaviour is known and acceptable, the application can retry the connection telling AcornSSL to ignore the error. Everything else can be handled as a simple “fail with warning” (UI, SysLog, whatever) action. Indeed, that’s the only logical behaviour for things such as “The certificate has been revoked (is on a Certificate Revocation List)”.

This will allow those who don’t want to deal with specifics to use AcornSSL more or less as designed (let the user decide at the time), while allowing the flexibility of permitting the application to make its own decisions.

But certainly:

then requiring every application to duplicate some logic to check all the cases, and any that might be added in future

is way off the mark. No application needs to check all of the cases. It’ll be more “is it this or this? if not, bail”.

That’s my €0,02…

I’ve already pointed out all of my “smart” printers that offer HTTPS for admin but use a self-signed certificate (makes one wonder why they bother?),

Because the issue isn’t whether you trust the connection or not so much as whether your transmitted data can be read en-route. That S in HTTPS means the data stream is encrypted and isn’t easy to read clear text. Of course other aspects of the “smart” devices usually mean that element of security is like fitting a 10 tumbler lock on a soggy paper bag.

As an application author I am happy with the revised proposal for the interface. I would tend to be using it via the higher-level URL module, and I don’t have a problem, for the use cases I have in mind, with the user being prompted if the certificate cannot be verified in some way.

Considering Steve’s comments about the scope, I think it’s totally reasonable to look at this from the bounty claimant’s perspective. I take my hat off to anyone working on the OS, particularly these big issues. The last thing I would want to see is anyone feeling pressured to deliver an enhanced scope, or that the community don’t appreciate their efforts.

If some people feel that a certain part of the deliverable doesn’t go far enough, then are they not welcome to extend it later? I cannot see what would be stopping anyone from creating their own certificate manager UI – might be a nice Configure/Boot plugin. I agree that a module popping up a box might be a bit odd, but if the relevant information is dumped somewhere, is it really a headache to go into a Certificate Manager and configure as necessary? Then the user would simply retry their operation, and it should work.

I don’t really understand why anyone would want to routinely let through connections to hosts with bad/expired certificates – and why would anyone be hosting such things? It’s a bit amateur-hour, really. Note that I don’t see self-signed like this: they just need adding via a CM interface.

Considering Steve’s comments about the scope, I think it’s totally reasonable to look at this from the bounty claimant’s perspective. I take my hat off to anyone working on the OS, particularly these big issues. The last thing I would want to see is anyone feeling pressured to deliver an enhanced scope, or that the community don’t appreciate their efforts.

Hear, hear. My earlier posts certainly weren’t intended as any sort of criticism, and of course the beauty of an open source OS is that we can tweak things later as required.

With that said, I think historically AcornSSL has been closed source. Does anyone know whether it’s intended to be opened once the bounty is complete?

I’d imagine that the new version is essentially a complete re-write (removing any licensing hurdles which may have prevented the release of the original), so it would be a bit silly to not release the source once it’s done.

Although I’ve already mentioned this to ROOL separately, I’m happy with the proposed changes – I think they should meet the needs of everyone, and make AcornSSL really practical :)

Setting FIOASYNC will generate an Internet event for various socket activity, but note that…

SWI Socket_Ioctl,handle,FIOASYNC, errors ‘Bad file descriptor’ when handle is an SSL handle.

Similarly, SWI AcornSSL_Ioctl,handle,FIOASYNC, errors ‘Bad context handle’ when handle is not an SSL handle (ie an integer).

However, the Internet Event which is generated by FIOASYNC always seems to use the non-SSL handle. This means that if FIOASYNC is used with SSL sockets, you need to use
both Socket_Creat
and AcornSSL_CreateSession
to be able to detect which event handles are of interest.

This means that the SocketWatch module can only be used with the integer non-SSL handles, as it uses Socket_Ioctl and the integer handles to recognise events.