The future of the Python ssl module
The future of the Python ssl module
Posted Jun 5, 2016 7:14 UTC (Sun) by noxxi (subscriber, #4994)In reply to: The future of the Python ssl module by Cyberax
Parent article: The future of the Python ssl module
With this argumentation a browser which lets anybody do a man in the middle attack on HTTPS connections and thus sniff your passwords is still fully functional. I don't share this view since protection against sniffing is a major reason that somebody uses HTTPS.
> Security is optional and at times not needed at all.
I think it is fine to explicitly switch off security if you don't need it. But I don't think that security should be off by default and that the developer needs to explicitly enable it, because in this case most developers will not do it as the past has shown.
> Since the API hadn't even allowed to specify certificates.
I very much doubt this. First it was possible all the years to add certificates to the systems CA store. Then even ssl.wrap_socket in python 2.6 had the ca_certs argument which let you specify your own CA store. And modules like requests also made use if this.
> It was not a bug, but a feature....And there was absolutely no urgency to break the world after 20 or so years without SSL validation.
If you consider this as a feature you are right. If you consider this a bug (like I do) then it should be fixed as soon as possible because it is a security problem.
Posted Jun 5, 2016 7:28 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
Moreover, trying to "secure" browser by installing additional certificates might be a bad idea if their private keys are not managed correctly.
> I think it is fine to explicitly switch off security if you don't need it. But I don't think that security should be off by default and that the developer needs to explicitly enable it, because in this case most developers will not do it as the past has shown.
> I very much doubt this. First it was possible all the years to add certificates to the systems CA store. Then even ssl.wrap_socket in python 2.6 had the ca_certs argument which let you specify your own CA store. And modules like requests also made use if this.
So developers quite explicitly have chosen not to care about certificates and simply used the defaults.
> If you consider this as a feature you are right. If you consider this a bug (like I do) then it should be fixed as soon as possible because it is a security problem.
Would you chose to live for several months without utilities to make sure they are secure?
Posted Jun 5, 2016 8:24 UTC (Sun)
by noxxi (subscriber, #4994)
[Link] (5 responses)
How many browsers are used only inside an internal network? I think that majority will be used outside so they should be implemented with security in mind even if the security is not needed in a few specific cases.
> Moreover, trying to "secure" browser by installing additional certificates might be a bad idea if their private keys are not managed correctly.
That's correct. But there is huge difference between insecure in all cases (not checking anything) and insecure in some specific situations (private key compromised).
> Nobody cares about security if their business-critical application is hard-down.
And nobody cares about "but it was fully functional" if their business-critical passwords are compromised. Exactly for this reason it is important that applications and libraries are secure by default so that developers are aware of the problems and knowingly can decide if they disable security fully or better add a new trusted CA.
> So developers quite explicitly have chosen not to care about certificates and simply used the defaults.
It might be true that you explicitly choose to ignore security and this makes also sense in the case of a watchdog. But the ssl library is not only used by you. And I'm pretty much sure that the majority of developers just lived with the defaults while not beeing aware that these defaults are insecure. So yes, it unnecessarily broke your application but on the other hand it probably made lots of other applications more secure. There is an xkcd which describes this kind of tradeoff: https://xkcd.com/1172/
> Would you chose to live for several months without utilities to make sure they are secure?
Would you chose to live without utilities because someone hacked these, like recently happened in the Ukraine? Fortunately they are actually starting to get more security aware in this environment and laws get passed to better protect critical infrastructures. And they are actively working to improve the security.
But what they probably will not do in a SCADA environment is to upgrade to a new software version without lots of testing, i.e. unlike you in your business critical environment.
Posted Jun 5, 2016 8:42 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> That's correct. But there is huge difference between insecure in all cases (not checking anything) and insecure in some specific situations (private key compromised).
If you install the certificates for these keys into your CA storage, then you open yourself to _undetectable_ MITM for anybody who obtains these keys.
> And nobody cares about "but it was fully functional" if their business-critical passwords are compromised.
> So yes, it unnecessarily broke your application but on the other hand it probably made lots of other applications more secure.
> Would you chose to live without utilities because someone hacked these, like recently happened in the Ukraine?
> But what they probably will not do in a SCADA environment is to upgrade to a new software version without lots of testing, i.e. unlike you in your business critical environment.
Posted Jun 5, 2016 23:05 UTC (Sun)
by bronson (subscriber, #4806)
[Link] (3 responses)
Posted Jun 6, 2016 5:55 UTC (Mon)
by noxxi (subscriber, #4994)
[Link] (2 responses)
The code changes do not cause DoS by themselves. The DoS is only caused in specific use cases in specific environment where the software relied on the previous default behavior and where the failure of the software after the update then caused a DoS . In other cases the code simply works as before and in yet other cases it will just break but not cause a DoS.
I don't know what exactly happened in this specific case from Cyberax where the change broke the watchdog and thus the setup of the site. But obviously a software upgrade was done on the system running a business critical application without up-front testing and maybe also without reading about the changes done by the software upgrade in detail. The release notes for Python 2.7.9 clearly stated the behavior changes.
While it is easy to complain about the changes to Python in this case I would recommend to better revise the process of installing untested software updates on critical systems, because you will find similar problems everywhere. Just look at the fallouts from CVE-2014-6321, where Microsoft had trouble to get a stable fix for a remote execution in their SChannel TLS library.
There is a reason that SCADA systems and other critical systems usually don't have the very latest system patches installed. In this environment any kind of software updates needs to be tested and approved by the vendor before they get shipped.
> to an extremely unlikely MITM?
Claiming that MITM is extremly unlikely is like claiming that the change causes an almost guaranteed DoS, i.e. exaggerating and making up "facts". Both MITM and DoS very much depend on the environment where the code is used.
But tools like firesheep have shown how easily MITM can be done (even though firesheep was for plain HTTP only the same thing would work with HTTPS when not validating certificates). And if it is possible and maybe easy too it will be done if the target is attractive. But the thing about MITM in a setup where you don't validate certificates is that you don't even realize that it happened. Thus you will not even realize if the change fixed your broken software, you will only realize if the change broke it.
Given that lots of security bugs are actually used in practice (Shellshock, Heartbleat,...) and cause serious damage I'm very much in favor of fixing such vulnerabilities fast, especially if they are trivially to exploit like this one. And yes, there will probably be collateral damage but there would be damage too if the vulnerability gets not fixed.
Posted Jun 10, 2016 1:55 UTC (Fri)
by mstone_ (subscriber, #66309)
[Link] (1 responses)
Posted Jun 16, 2016 17:29 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
We also support Ubuntu cloud AMIs that started to include Python changes that broke everything. That was fun to debug and fix...
Posted Jun 5, 2016 16:00 UTC (Sun)
by flussence (guest, #85566)
[Link] (2 responses)
Posted Jun 5, 2016 21:03 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Jun 6, 2016 18:37 UTC (Mon)
by flussence (guest, #85566)
[Link]
The future of the Python ssl module
Correct. If a browser is used only inside the internal network then it's perfectly fine to not use HTTPS authentication or even HTTPS in the first place.
Nobody cares about security if their business-critical application is hard-down.
Except that nobody did this. Watchdog doesn't care about security (only about reachability) and works only inside the trusted local network. If somebody is doing MITM in it, then it's already screwed.
Can you provide your address? I'm going to cut off your power lines because the SCADA system on your power plant is likely to be vulnerable. So you MUST get a local battery backup and a generator. Otherwise YOU'RE NOT SECURE!!!11111111!
The future of the Python ssl module
The future of the Python ssl module
Sure. That's why for a _browser_ it makes much sense to enforce HTTPS certificates. However, a lot of Python scripts _are_ designed only for internal networks.
A lot of internal systems use HTTPS just to avoid sending HTTP basic authentication passwords in the clear. However, their private keys are not managed securely so it's easy to pull them off.
However the likelihood of this resulting from a MITM attack inside a trusted LAN is way too low. This is NOT a new issue, it has been known for literally a _decade_ and simple probability of being attacked through this vector is way too low.
So is turning off the power. And no, I doubt that this whole SSL fiasco succeeded in preventing even one real-world attack.
Yes, I would.
No. There's a SECURITY (!111!oneoneone!) vulnerability, so they MUST turn off systems that have been working fine for decades in order to protect from one unlikely attack vector. No compromises are possible in the struggle for security!
The future of the Python ssl module
The future of the Python ssl module
The future of the Python ssl module
The future of the Python ssl module
The future of the Python ssl module
If real-world utilities were as badly built as some of this software, security would be at the bottom of my list of priorities - below things like keeping up to date on my power socket adapters, memorizing which direction I have to turn the kitchen taps this week in order for them to put out water instead of gas, and planning an emigration to a country with some actual standards.
The future of the Python ssl module
The future of the Python ssl module