[HN Gopher] OpenSSL 3.0 released; relicensed to Apache-2.0
___________________________________________________________________
OpenSSL 3.0 released; relicensed to Apache-2.0
Author : jabo
Score : 64 points
Date : 2021-09-20 21:46 UTC (1 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| gatronicus wrote:
| Since there were so many TLS security bugs due to it's
| complexity, is there any push to replace it with something
| simpler and with less choices and attack surface?
|
| Google gave us HTTP/2/3, but don't seem to care about fixing TLS.
| jborean93 wrote:
| IIRC HTTP3/QUIC mandates TLS[1][2] so it itself still relies on
| TLS. It seems like it's set on TLS 1.3 as a baseline and I
| would hope the negotiation of the protocol is future compatible
| but I will admit I haven't fully read the RFCs.
|
| [1] https://datatracker.ietf.org/doc/html/rfc9000#section-1 [2]
| https://datatracker.ietf.org/doc/html/rfc9001
| nemothekid wrote:
| > _Google gave us HTTP /2/3, but don't seem to care about
| fixing TLS._
|
| Google is working on BoringSSL / Tink, which I believe is API
| compatible, but supports a lot less features. However I think a
| better way forward might be RustTLS, an implementation which is
| memory-safe. There is already support in Curl[1], showing there
| is a path forward for usage in languages other than Rust.
|
| [1] https://daniel.haxx.se/blog/2021/02/09/curl-supports-
| rustls/
| mrb wrote:
| TLS the protocol has been simplified in version 1.3, with the
| goal of reducing complexity to improve security.
|
| OpenSSL the implementation was forked a few times also with the
| goal of improving security. Notable forks: LibreSSL, BoringSSL.
|
| PS: for all those confused why OpenSSL skipped version 2, it
| seems it's because FIPS builds identified themselves as version
| 2 (thanks to poster below!) Also the changelog explains the new
| version naming scheme:
|
| """
|
| Switch to a new version scheme using three numbers
| MAJOR.MINOR.PATCH.
|
| Major releases (indicated by incrementing the MAJOR release
| number) may introduce incompatible API/ABI changes.
|
| Minor releases (indicated by incrementing the MINOR release
| number) may introduce new features but retain API/ABI
| compatibility.
|
| Patch releases (indicated by incrementing the PATCH number) are
| intended for bug fixes and other improvements of existing
| features only (like improving performance or adding
| documentation) and retain API/ABI compatibility.
|
| """
|
| Quoted from: https://www.openssl.org/news/changelog.html So
| there won't be a 3.0.0a, 3.0.0b, etc. They want to make it
| clear it will be 3.0.1, 3.0.2, etc
| geofft wrote:
| It's also because the FIPS builds of OpenSSL 1.x identified
| themselves as 2.x.
| mrb wrote:
| I didn't know! Yeah that seems to be the main reason
| wolf550e wrote:
| TLS 1.3 is much better than TLS 1.2, and has fewer options and
| knobs (e.g. no need to choose cipher suites), but it is not
| what a modern protocol designed from scratch would look like.
| For that you should look at WireGuard, or the general Noise
| Protocol Framework.
|
| For custom protocols, libsodium would be a popular modern
| approach. If you need compatibility with TLS, try locking down
| TLS to only version 1.3, or if you can't do that, lock it down
| to only TLS 1.2 with tls_ecdhe_rsa_with_aes_128_gcm_sha256.
| chasil wrote:
| This has been useful advice for many years, although
| restricting to AEAD is best when possible.
|
| https://hynek.me/articles/hardening-your-web-servers-ssl-
| cip...
| nwjsmith wrote:
| Google employ at least one OpenSSL committer and have their own
| simpler version of the library, BoringSSL.
| LeoPanthera wrote:
| Maybe this is paranoid but they tell you how to check the hash of
| the download using openssl itself.
|
| A compromised version of openssl could detect itself and return
| the "correct" hash.
| beebmam wrote:
| This makes sense if you don't check a package's hash before you
| install it.
| j_walter wrote:
| Use your current version of openssl...
| ronsor wrote:
| ... and if your current version of openssl is already
| compromised, nobody can help you anyway.
| manquer wrote:
| There are always components you cannot fully trust . Ken
| Thompson's reflections on trusting trust [1] comes to mind
|
| Trust depends on threat model, if your threat model
| includes such actors/potential attack vectors then you
| should worry, ultimately you are depending on someone code
| for any reasonable abstractions (even ignoring chip level
| comprises)
|
| [1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_198
| 4_Ref...
| marcodiego wrote:
| There is a way out: a simple assembler that can be hand
| typed and easily checked that allows the user to type-in
| a more advanced one ... until a compiler or interpreter
| with checked source code can be run and bootstrap tools
| whose source can be checked by hashes.
|
| It is already doable: https://bootstrappable.org/
| https://gitlab.com/janneke/mes
| jamesmishra wrote:
| Agreed.
|
| For other HN users, this is the "Reflections on Trusting Trust"
| issue.
|
| https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
| kingforaday wrote:
| I am surprised by the lack of corporate sponsors [1].
|
| 1. https://www.openssl.org/support/acks.html
| kelnos wrote:
| I'm not, sadly. It's pretty standard in our industry that
| companies will use a ton of open source software without giving
| back at all, or giving back many orders of magnitude less than
| they get.
| kingforaday wrote:
| It may be an awareness problem too. I know personally I've
| enjoyed having OpenSSL around and just became a GitHub
| sponsor (under same HN username).
| gtirloni wrote:
| https://www.openssl.org/community/thanks.html
|
| "The following organizations who contribute staff time to work
| on the project (alphabetically): Akamai, Cryptsoft, Google,
| Oracle, Red Hat, Siemens, and Softing."
| wbl wrote:
| Do you enjoy perl constructed header files? VMS support?
| Inconsistent error codes across APIs? Then OpenSSL is for you.
|
| None of the problems have been fixed.
| [deleted]
| skissane wrote:
| > VMS support?
|
| Is it a bad thing to support OpenVMS, given it is still an
| actively supported operating system? It isn't used anywhere
| near as much as it used to be, but it is still used. It has
| even been ported to x86-64.
| ncann wrote:
| Reminds me of this classic:
|
| https://web.archive.org/web/20201224212934/https://www.peere...
| seneca wrote:
| Did they reject the PRs you sent implementing those updates?
___________________________________________________________________
(page generated 2021-09-20 23:00 UTC)