On Sun, 31 Aug 2014 16:45:42 +1000, Nick Coghlan email@example.com wrote:
On 31 August 2014 16:16, Donald Stufft firstname.lastname@example.org wrote:
On Aug 31, 2014, at 2:09 AM, Nick Coghlan email@example.com wrote:
At the same time, we need to account for the fact that most existing organisations still trust in perimeter defence for their internal network security, and hence tolerate (or even actively encourage) the use of unsecured connections, or skipping certificate validation, internally. This is actually a really terrible idea, but it's still incredibly common due to the general failure of the technology industry to take usability issues seriously when we design security systems (at least until recently) - doing the wrong "unsafe" thing is genuinely easier than doing things right.
Just a quick clarification in order to be a little clearer, this change will (obviously) only effect those who trust perimeter security *and* decided to install an invalid certificate instead of just using HTTP. I'm not saying that this doesn't happen, just being specific (I'm not actually sure why they would install a TLS certificate at all if they are trusting perimeter security, but I'm sure folks do).
It's the end result when a company wide edict to use HTTPS isn't backed up by the necessary documentation and training on how to get a properly signed cert from your internal CA (or, even better, when such an edict comes down without setting up an internal CA first). Folks hit the internet instead, find instructions on creating a self-signed cert, install that, and tell their users to ignore the security warning and accept the cert. Historically, Python clients have "just worked" in environments that required a click-through on the browser side, since you had to opt in to checking the certificates properly.
Self-signed certificates can also be really handy for doing local testing - you're not really aiming to authenticate the connection in that case, you're just aiming to test that the secure connection machinery is all working properly.
Self-signed certificates are not crazy in an internal corporate environment even when properly playing the defense in depth game. Once you've acked the cert the first time, you will be warned if it changes (like an ssh host key). Sure, as Nick says the corp could set up an internal signing authority and make sure everyone has their CA...and they *should*...but realistically, that is probably relatively rare at the moment, because it is not particularly easy to accomplish (distributing the CA everywhere it needs to go is still a Hard Problem, though it has gotten a lot better).
Given the reality of human nature, even when the documentation accompanying the HTTPS initiative is good, there will *still* be someone who hasn't followed the internal rules, yet you really need to talk to the piece of infrastructure they are maintaining. At least that one is short term problem (for some definition of "short" that may be several months long), but it does exist.
In addition, as has been mentioned before, self-signed certs are often embedded in *devices* from vendors (I'm looking at you, Cisco). This is another area where security conciousness has gotten better (the cert exists) but isn't good yet (the cert is self-signed and replacing it isn't trivial when it is even possible; and, because the self-signed cert happens by default....it gets left in place). And in the case of those embedded certs, the cert can wind up *invalid* (expired) as well as self-signed. (This last item is where my concern about being able to talk to invalid certs comes from.)
And yes, I have encountered all of this in the wild.