Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL Security Advisory

openssl.org

Post reply on HN
Print view View original

61–70 of 142 posts

Re: OpenSSL Security Advisory

#61

Post by d_theorist »

ultramancool wrote: post #52
calpaterson wrote: post #46

Earlier quoted context omitted.

Yes but in practice a lot of them do, for example, when they download a library from PyPI or rubygems...? Unless we're talking just about when people use client certificates as authentication?

> PyPI or rubygems These are not activities which a web server does though. These are activities usually triggered by developers or administrators, not by web servers remotely and they have to do with a web application, not a web server. And even then, for this attack to be meaningful you'd need to have active MITM between the server and PyPI or rubygems at the time when the developer or administrator was updating th…

>And even then, for this attack to be meaningful you'd need to have active MITM between the server and PyPI or rubygems

Yeah. Which is pretty much the thing (or one of the things anyway) that TLS is supposed to prevent!

>These are activities usually triggered by developers or administrators, not by web servers remotely and they have to do with a web application, not a web server.

Some strange distinctions. A server running a web application may well want to make requests to PyPI when being provisioned.

Re: OpenSSL Security Advisory

#62

Post by makomk »

pilif wrote: post #4

> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be b…

Unfortunately, I suspect this feature may be necessary in practice in order to actually expire old, insecure CA certificates that are still in widespread use.

Re: OpenSSL Security Advisory

#63

Post by jerf »

aninteger wrote: post #43

Why has the adoption of alternative SSL software been so low. We have libressl, boringssl, something from Amazon? Very few Linux distributions seem interested in shipping alternative SSL software.

Probably because once you wrap your code around one SSL stack it's hard to migrate it to another. So you stick to the one you use first. OpenSSL, for instance, isn't just an SSL library... since C has no standardized "stream" functionality, it's a whole big generic streaming library with pluggable modules for various streams and the ability to write your own... once you're stuck to that you can get stuck pretty hard if you don't properly wrap it with abstraction, which C is not, ahhh... let's say it's not really the best at that sort of thing anymore, which is of course partially because every language since C has known that it needs to be better than C at this to even be considered by anybody.

Re: OpenSSL Security Advisory

#64

Post by tedunangst »

kaeso wrote: post #35
pilif wrote: post #4

> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be b…

This seems to be a common opinion recently, see https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...

It's not a particularly new opinion, just one people refuse to learn. Prior example from 2008: http://www.joelonsoftware.com/items/2008/03/17.html

Re: OpenSSL Security Advisory

#66

Post by TheDong »

aninteger wrote: post #43

Why has the adoption of alternative SSL software been so low. We have libressl, boringssl, something from Amazon? Very few Linux distributions seem interested in shipping alternative SSL software.

You missed the two oldest and most mature alternatives: libnss (firefox) and gnutls.

Re: OpenSSL Security Advisory

#67

Post by Arnt »

kaeso wrote: post #35
pilif wrote: post #4

> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be b…

This seems to be a common opinion recently, see https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...

But Jon Postel didn't mean what people now think he did.

His famous principle is about border cases, when the spec is vague, handwavy or thought by some to be vague. It's not about the other cases.

Remember that Jon Postel was the RFC editor. He didn't want anyone to ignore the RFCs, he wanted the RFCs to be readable and pleasant, and he wanted implementers to do the right thing when when an RFC erred on the side of readability.

FWIW I wrote a blog post about this a few years ago, http://rant.gulbrandsen.priv.no/postel-principle

Re: OpenSSL Security Advisory

#68

Post by toast0 »

pilif wrote: post #4

> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be b…

Alternate chains aren't a broken input issue; it's an issue where not all clients have the same CAs; so if you need to chain to an old 1024-bit root to take care of really old clients, newer clients without 1024-bit roots should be able to validate still. Older versions of openssl need to keep the 1024-bit root around, because the only validate the full chain provided by the server.

Re: OpenSSL Security Advisory

#69

Post by andrewstuart2 »

pilif wrote: post #4

> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be b…

Not only that, but with less and simpler code, there's less cognitive disincentive for people to take a look at it, see what it's doing, and verify that it does what it says it does.

Re: OpenSSL Security Advisory

#70

Post by KayEss »

d_theorist wrote: post #61
ultramancool wrote: post #52

Earlier quoted context omitted.

> PyPI or rubygems These are not activities which a web server does though. These are activities usually triggered by developers or administrators, not by web servers remotely and they have to do with a web application, not a web server. And even then, for this attack to be meaningful you'd need to have active MITM between the server and PyPI or rubygems at the time when the developer or administrator was updating th…

>And even then, for this attack to be meaningful you'd need to have active MITM between the server and PyPI or rubygems Yeah. Which is pretty much the thing (or one of the things anyway) that TLS is supposed to prevent! >These are activities usually triggered by developers or administrators, not by web servers remotely and they have to do with a web application, not a web server. Some strange distinctions. A server r…

This should only be the case for the build server that creates the packages that get installed on production.
Post reply on HN