This is a pretty low-information post and the discussion is therefore pretty generic. In such cases it's better to wait until the thing actually comes out, and with it enough information to support a specific discussion.
dang, do you think the fact that this is announcing a date in the future to look out for potentially an exploitable issue and folks may want to discuss ways to mitigate that?
> HIGH Severity. This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control
So something to make sure you update, but not a Heartbleed level concern
(I am also currently available on part-time freelance basis, feel free to contact me if you need commercial support on your endeavour to structurally address your TLS security issues.)
You can find it if you have a generic "suspicious looking code" check. And you can find it if you have a protocol regression test. But do you have a model of TLS that proves incorrect code paths like this don't exist?
Apps build rustls into a fat binary, which doesn't get updated on day zero by the OS package manager. It requires a new release by the app maintainer for each app.
Any idea when rustls will hit 1.0? I feel a little unsafe using a <1.0 library because (assuming it's following SemVer) as it might not be "done"/production ready and the API might change a lot before it hits 1.0.
Do you support ppc64le? WebAssembly? Not a requirement for me, but the fact that ring has no portable implementations is concerning. How do you verify correctness without a baseline? Evercrypt seems like a much better option on that front.
I am all for shared libraries. Update openssl and everything else gets the patch. With rust/go, now I have to wait for all the authors to release their fat binaries of the same dependencies
There was a post here a few days ago by one of the Gentoo maintainers talking about how static builds are bad and this exact reason (security vulnerability that touches lots of things) was one mentioned.
Site appears to be hugged to death. Here's the full text of the email:
The OpenSSL project team would like to announce the forthcoming
release of OpenSSL version 1.1.1k.
This release will be made available on Thursday 25th March 2021
between 1300-1700 UTC.
OpenSSL 1.1.1k is a security-fix release. The highest severity issue
fixed in this release is HIGH:
https://www.openssl.org/policies/secpolicy.html#high
Yours
The OpenSSL Project Team
For the average developer what do I need to do? I don't use OpenSSL directly but I'm pretty sure some parts of my tech stack use it as a dependency. Do I simply need to run `apt-get upgrade` on the 25th?
> Do I simply need to run `apt-get upgrade` on the 25th?
Mostly, but some details matter.
Make sure that when you do the upgrade, that you are fetching the fixed version. Check for the security announcement and see which version things get fixed in:
Watch the debian security mailing list for information about when their fix is available to others through apt: https://lists.debian.org/debian-security-announce/ In general you should be following this list if you're managing production services running debian or ubuntu.
Can't believe that, in God's year 2021, 3rd millennia, Earth, we're still using security libraries written in what is essentially a portable assembly language, doing silly things like pointer arithmetic, manually allocating memory, and other chainsaw juggling feats.
I swear some day we'll look back to this period with bewilderment: son, in those days people used to smoke carcinogens for their taste, drive their own cars and treat mental disorders with an ice pick in the prefrontal cortex. Trully mad men would even implement X.509 in unsafe languages.
It would be good to know if this vulnerability was related to memory safety before pinning it on memory safety. You can get cryptography just as wrong in Rust or Go.
> Can't believe that, in God's year 2021, 3rd millennia, Earth, we're still using security libraries written in what is essentially a portable assembly language, doing silly things like pointer arithmetic, manually allocating memory, and other chainsaw juggling feats.
I suppose the flip side of this view is just how easy it is to underestimate what a truly enormous amount of work it would take to completely reimplement all these 'chainsaw juggling feats' that are used all over the place, day in and day out.
The problem is not the language! If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the software of all these critical embedded system is written in C.
The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones. The problem is that such a critical software (well, relatively critical, because if there is a bug in a security library nobody dies in the end) is not written to that standards.
As one of the OpenSSL maintainers, I would like to move away from C and probably to rust. But the problem is that C is the most portable language, and rust's platform support just isn't close enough.
We don't know what the vulnerability is yet. Sure it could be a buffer overflow, readily possible in a language like C, or could be a bug in the crypto/implementation itself, no memory safe language will save you there.
so..`yholio` Rants asside what is your valuable contribution to the library or creating a new impecable one? I'm acutally glad we have such powerfull library available for free and using open source code so we can audit it and find bugs
I just started wondering, if things were any better if security libraries were written in higher level languages, depending on on a huge run-time support system that is written in what is essentially a portable assembly language, doing silly things like pointer arithmetic, manually allocating memory and so on... :)
>in those days people used to smoke carcinogens for their taste, drive their own cars and treat mental disorders with an ice pick in the prefrontal cortex
Do you imagine a future where nobody is able to drive cars? Not even for fun?
I want all serious software that's written in C to be replaced with something like Rust, but I write C for fun. It's fun to do dangerous things. It's just bad to have danger as the modus operandi.
1. There is no such thing as a safe or unsafe language. Safety is relative and impossible to guarantee. Even "memory safety" often just means "memory tradeoffs".
2. Inline assembly is often a necessary evil to create implementations of crypto libraries in C... not using it would be worse.
3. It's all machine code under the covers. Whether one developer poorly juggles chainsaws or your high-level language poorly juggles chainsaws is not a question of better or worse, but taste.
4. It's X.509. It sucks in every language.
5. Just because it's in C doesn't mean it sucks. There are alternative libraries that intentionally avoid sucky design. (https://nacl.cr.yp.to/internals.html)
6. Show me another language that's as portable and powerful as C, and cryptographers will probably start using it.
It's swiss-army chainsaw juggling with a kitchen-sink of unnecessary features, bloat, and poor coding hygiene.
C isn't the problem per se, it's the lack of quality, formal rigor, and testing that these slap-dash developers foist on the world. It's a steaming pile, and people wonder why it has security vulnerabilities over and over again. It's doing the same damn thing and expecting a different result: C maybe part of it, but its developers just aren't that great.
I would probably use OpenSSL in preference to LibreSSL at this point. The dev culture point you’re trying to make hasn’t really been true for many years.
Somewhat ironically to this circumstance (assuming it doesn't affect LibreSSL), the Void team has just switched back away from LibreSSL which it shipped by default with for years.
[+] [-] dang|5 years ago|reply
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
[+] [-] bluejekyll|5 years ago|reply
granted, much of the discussion is not about that at this point, though there is a bit: https://news.ycombinator.com/item?id=26547279
[+] [-] jonas21|5 years ago|reply
The last high severity fix in OpenSSL was this past December.
[1] https://www.openssl.org/policies/secpolicy.html
[+] [-] 0x003|5 years ago|reply
So something to make sure you update, but not a Heartbleed level concern
[+] [-] hosteur|5 years ago|reply
[+] [-] dochtman|5 years ago|reply
What would your team need to be able to migrate to a different TLS stack that so far has proven to be safer, and passed its first security audit with flying colors? (https://github.com/ctz/rustls/blob/main/audit/TLS-01-report....)
(I am also currently available on part-time freelance basis, feel free to contact me if you need commercial support on your endeavour to structurally address your TLS security issues.)
[+] [-] astrange|5 years ago|reply
Look at gotofail: https://www.imperialviolet.org/2014/02/22/applebug.html
You can find it if you have a generic "suspicious looking code" check. And you can find it if you have a protocol regression test. But do you have a model of TLS that proves incorrect code paths like this don't exist?
[+] [-] sounds|5 years ago|reply
[+] [-] ancarda|5 years ago|reply
[+] [-] CameronNemo|5 years ago|reply
[+] [-] Snawoot|5 years ago|reply
[+] [-] tedunangst|5 years ago|reply
[+] [-] 29athrowaway|5 years ago|reply
[+] [-] tptacek|5 years ago|reply
[+] [-] orblivion|5 years ago|reply
[+] [-] ashneo76|5 years ago|reply
[+] [-] edoceo|5 years ago|reply
[+] [-] jez|5 years ago|reply
[+] [-] janvidar|5 years ago|reply
* A TLS client using session resumption may cause a use-after-free.
[+] [-] smasher164|5 years ago|reply
[1] https://hacl-star.github.io/HaclValeEverCrypt.html
[+] [-] ollien|5 years ago|reply
https://web.archive.org/web/20210322203019/https://mta.opens...
[+] [-] trinovantes|5 years ago|reply
[+] [-] throw0101a|5 years ago|reply
Mostly, but some details matter.
Make sure that when you do the upgrade, that you are fetching the fixed version. Check for the security announcement and see which version things get fixed in:
* https://www.debian.org/security/
Once the CVE is known, you can also see which versions are vulnerable and which are fixed:
* https://security-tracker.debian.org/tracker/CVE-2020-1971
You may have to restart some services. The checkrestart utility is handy to find these:
* https://packages.debian.org/buster/debian-goodies
* https://packages.debian.org/search?keywords=debian-goodies
[+] [-] qbasic_forever|5 years ago|reply
[+] [-] tedunangst|5 years ago|reply
[+] [-] vbezhenar|5 years ago|reply
[+] [-] dorianmariefr|5 years ago|reply
[+] [-] seaghost|5 years ago|reply
[+] [-] yholio|5 years ago|reply
I swear some day we'll look back to this period with bewilderment: son, in those days people used to smoke carcinogens for their taste, drive their own cars and treat mental disorders with an ice pick in the prefrontal cortex. Trully mad men would even implement X.509 in unsafe languages.
[+] [-] tptacek|5 years ago|reply
[+] [-] usefulcat|5 years ago|reply
I suppose the flip side of this view is just how easy it is to underestimate what a truly enormous amount of work it would take to completely reimplement all these 'chainsaw juggling feats' that are used all over the place, day in and day out.
[+] [-] alerighi|5 years ago|reply
The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones. The problem is that such a critical software (well, relatively critical, because if there is a bug in a security library nobody dies in the end) is not written to that standards.
[+] [-] kroeckx|5 years ago|reply
[+] [-] jamescun|5 years ago|reply
[+] [-] rafaelturk|5 years ago|reply
[+] [-] oolonthegreat|5 years ago|reply
[+] [-] dvdkhlng|5 years ago|reply
[+] [-] Klwohu|5 years ago|reply
[deleted]
[+] [-] 29athrowaway|5 years ago|reply
[+] [-] maerF0x0|5 years ago|reply
https://groups.google.com/g/golang-nuts/c/0za-R3wVaeQ
[+] [-] elwell|5 years ago|reply
[0] - JS ¯\_(ツ)_/¯
[+] [-] ancarda|5 years ago|reply
Do you imagine a future where nobody is able to drive cars? Not even for fun?
I want all serious software that's written in C to be replaced with something like Rust, but I write C for fun. It's fun to do dangerous things. It's just bad to have danger as the modus operandi.
[+] [-] throwaway823882|5 years ago|reply
2. Inline assembly is often a necessary evil to create implementations of crypto libraries in C... not using it would be worse.
3. It's all machine code under the covers. Whether one developer poorly juggles chainsaws or your high-level language poorly juggles chainsaws is not a question of better or worse, but taste.
4. It's X.509. It sucks in every language.
5. Just because it's in C doesn't mean it sucks. There are alternative libraries that intentionally avoid sucky design. (https://nacl.cr.yp.to/internals.html)
6. Show me another language that's as portable and powerful as C, and cryptographers will probably start using it.
[+] [-] airhead969|5 years ago|reply
C isn't the problem per se, it's the lack of quality, formal rigor, and testing that these slap-dash developers foist on the world. It's a steaming pile, and people wonder why it has security vulnerabilities over and over again. It's doing the same damn thing and expecting a different result: C maybe part of it, but its developers just aren't that great.
[+] [-] snvzz|5 years ago|reply
For some reason, companies decided to put money into the known-bad openssl instead, as if money could fix a bad development culture.
[+] [-] tptacek|5 years ago|reply
[+] [-] tubbyjr|5 years ago|reply
Discussion: https://github.com/void-linux/void-packages/issues/20935
[+] [-] mjevans|5 years ago|reply
[+] [-] danielheath|5 years ago|reply
[+] [-] sekh60|5 years ago|reply