aka BackdoorSSL ?
is that the one?
With developers still struggling to plug vulnerabilities in the open source OpenSSL crypto library, Google has spun off a new fork of the project based on its own, internal work with the code, dubbed BoringSSL. "We have used a number of patches on top of OpenSSL for many years," Google dev Adam Langley said in a blog post …
Being serious, it's named BoringSSL in the hope that in future it won't give rise to any excitement. Better fifty years of Europe than a cycle of Cathay*, said Tennyson, but if you are running large websites, boring reliability trumps excitement every time.
*He changed his mind later and decided progress was a bad thing. But that was because he had noticed how quickly progress itself becomes boring. If he was around for the Internet age, I think it would reinforce his prejudice.
It's hard to see how why this should be labeled boring when it includes a bunch of patches that "are a little too experimental."
The patches are experimental because they alter API or ABI. BoringSSL is boring because it strips back what an SSL library does from "everything + the very latest in development protocols" to "enough to make an encrypted connection and verify keys".
One of the main reasons heartbleed had such an effect was that almost anyone who offered OpenSSL on their webserver had been forced to upgrade to the newer, "more secure" OpenSSL 1.0 series in order to pass "security audits" which are simply "Is version > x".
OpenSSL may not be the only SSL implementation, but it is free (as in speech if not beer). Givien the difficulty of getting cryptographic implementations right it might be better to concentrate resources on implementing and making secure a single free implementation, whether OpenSSL, LibreSSL, or another, than to have competing implementations, each insecure in its own ways.
The problem is, the management of the OpenSSL project have been accused of not properly releasing information for risk assessment to affected parties. This creates a situation where meaningful collaboration cannot continue.
Combine with the facts that both projects remove element that OpenSSL maintains (API compatibility for BoringSSL, and OS support and FIPS140-2 support for LibreSSL). Overall I think these will be likely be more secure due to decreases in complexity that are things the OpenSSL project will not accept.
Does anyone know which protocols the new software supports and which cipher suites? And then how does that compare/differ to vanilla OpenSSL? From what I can work out from a quick scan of the linked-to git repository it seems to basically be the same as OpenSSL but maybe not quite as many cipher suites supported. But I could well be wrong.
I don't really trust SSL/TLS whatever any more. I am not capable of auditing the code or algos myself and I don't know anyone who is.
So, I would hope I would be able to look to my govt to provide that assurance.
Hmmm, nope, they have no IT skills beyond the ability to stroke something I'd prefer to be made into cider.
I'm an IT consultant and I studied mathematics to Civil Engineering graduate standard (some years ago) - ie I can add 1 and 1 and in most cases get an answer or at least a bloody good philosophical discussion. I don't think I am particularly daft.
There's plenty of links out there - just search for Google NSA. How genuine any/all of them are - well, that's up for debate. But given the number of links and variety of sources, I for one am reasonably satisfied there's cause for concern.
... of course, there are those out there in whose eyes Google can do no wrong (for whatever reason).
But yes, Mr. O.P. - let's see exactly where you're getting your information from and whether the source is credible enough to be considered "proof".
Since I consider the Internet one giant "party line", as in telephone systems, I never put any critical info on the internet, however banks, insurance cos., brokers, etc. that I deal with do, thus security is a concern. Since one of my browsers is Google Chrome that never updates, won't properly display and offers rudimentary help, suggests help forums and in the final analysis instructs to reset to factory defaults, then my suggestion would be to "work out the bugs" and you will probably create a secure SSL, without more experimentation. If binary systems were so great, banks would not be robbed of millions of dollars via computer vs. the old wire system that went bank to bank. The bank then handled the individual account.
In theory it is a good thing to have several different crypto libraries and toolsets available instead of just one. Keeping things diversified ensures that the failure of a single project won't spell doom for everyone, everywhere for a long time. Of course the fact that Google contributes to both of the other two "competitors", as it does to one of its main competitors in the browser market (Mozilla), might not be the healthiest state of affairs. In fact it's probably very unhealthy. Even before LibreSSL there was yet another, mostly unmentioned, alternative to OpenSSL -- NSS (Network Security Services, originally developed by Netscape and now maintained by a group that includes Google, Red Hat, Oracle and AOL). I suspect that the reason NSS isn't mentioned much is that so many for so long were determined to establish OpenSSL as the "one ring to rule them all" in the crypto space. After all it had "open" in its name, and an svn repository you could look at (if you dared!). Bob Beck's recent criticisms of both the OpenSSL Foundation's activities ("a for profit corporation in Maryland that amounts to a FIPS consultancy") and their code ("Run away!") has been substantive and sadly neglected by the ("dumb it down if you want eyes on your advertising") press (see the video here). What is makes clear is that the hopes of those who thought standardizing everyone on that single library/toolset was an empty one, and is a mistake that should not be repeated.
Biting the hand that feeds IT © 1998–2020