TCP/IP bounty beta release
Pages: 1 2 3 4 5 6 7 8 9 10 11
Martin Avison (27) 1479 posts |
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. |
André Timmermans (100) 648 posts |
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. |
Steve Revill (20) 1361 posts |
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:
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. |
Steve Pampling (1551) 8128 posts |
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. 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. |
Steve Revill (20) 1361 posts |
I mean ‘bad’ in the sense of ‘untrusted’. That’s AcornSSL’s view of the world. |
Frank de Bruijn (160) 228 posts |
Thanks. That looks like what we need. |
Rick Murray (539) 13754 posts |
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. We’re getting there, but there are degrees of untrusted.
(^_^) |
Steve Revill (20) 1361 posts |
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. |
Rick Murray (539) 13754 posts |
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.
…unless they wish to revoke the “accept always and forever” permission? |
Doug Webb (190) 1156 posts |
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. |
Chris Mahoney (1684) 2162 posts |
It looks like this:
Thank you; just what I needed in my case :) |
Steve Pampling (1551) 8128 posts |
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. |
Steve Revill (20) 1361 posts |
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… |
Dave Higton (1515) 3480 posts |
Perhaps we should set out the reasons why a certificate should be questioned or rejected. - Mismatch with host 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. |
Steve Revill (20) 1361 posts |
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. |
Steve Pampling (1551) 8128 posts |
Perhaps we should set out the reasons why a certificate should be questioned or rejected.
Which I suspect may be the coded behaviour |
Sprow (202) 1150 posts |
Off the top of my head:
OK, OK, I cheated and looked at the list.
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. |
Rick Murray (539) 13754 posts |
Hmm…
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 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? 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:
With this in mind, and noting Sprow’s comments, there should be three behaviours:
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. 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:
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… |
Steve Pampling (1551) 8128 posts |
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. |
Matthew Phillips (473) 714 posts |
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. |
Richard Walker (2090) 431 posts |
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. |
Chris Mahoney (1684) 2162 posts |
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? |
Jeffrey Lee (213) 6048 posts |
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. |
Andrew Rawnsley (492) 1440 posts |
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 :) |
Martin Avison (27) 1479 posts |
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 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. |
Pages: 1 2 3 4 5 6 7 8 9 10 11