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

51–60 of 142 posts

Re: OpenSSL Security Advisory

#51

Post by parasubvert »

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...

The problem isnt so simple in the world of large scale protocol design - standards are rarely successful when imposed, they're usually adopted as a reflection of the current implementations. And when you're dealing with multiple independent implementations the variance can be subtle, and the standards often are broken or at best under-specified at first.

When dealing with integration among many parties, there is tremendous pressure to just "make it work". The web arguably is an example of this - the standards were post-facto representations of what's already implemented.

Of course we are all hating the long term implications on our codebases , but "let's force everyone to do it one way through strict behaviour" seems to discount the social dynamics of interoperability.

Moving away from Postel's principle in production will not lead to successful open and interoperable implementations, it will rather trend towards towards one single implementation , likely open source, that is shared and tweaked by all. That has some positive (interop!) and negative implications (limited ability to innovate / dragged down into programmer religions, etc).

Re: OpenSSL Security Advisory

#52

Post by ultramancool »

calpaterson wrote: post #46
ultramancool wrote: post #28

Earlier quoted context omitted.

Yes and most web servers do not use client certificates and do not have any need to validate certificates.

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 this. In a good datacenter, this should not be possible. Employees of the DC and national security agencies, which may be able to perform active attacks in such datacenters would probably be the biggest risk.

Re: OpenSSL Security Advisory

#53

Post by parasubvert »

stonemetal wrote: post #48
kaeso wrote: post #35

Earlier quoted context omitted.

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

I wouldn't say he is wrong, so much as you just need a dev mode where strict acceptance is the order of the day. You need people to learn to produce correct results, but still be resilient in the field.

This x10. Strict Dev modes are helpful. Strict everywhere just means that there will only be one successful implementation that everyone uses.

Re: OpenSSL Security Advisory

#55

Post by valarauca1 »

tomjen3 wrote: post #37

How is it that we still depend on something so broken?

If you think you can write a better implementation then put your hands where your keyboard is. Show us the code.

If not, submit patches.

An OpenSSL team member said, "If you're in a position to offer technical criticism you're in a position to offer technical help." While it sounds like their pleading for help, its because WE ARE. There are 3 full time maintainers, 1 is a dog :P and only ~10-16 regular patch submitters.

Re: OpenSSL Security Advisory

#57

Post by batou »

coolowencool wrote: post #44

"No Red Hat products are affected by this flaw (CVE-2015-1793), so no actions need to be performed to fix or mitigate this issue in any way." https://access.redhat.com/solutions/1523323

Well there goes my long laborious afternoon of sysadmin work that I wasn't looking forward to! :-)

Re: OpenSSL Security Advisory

#58

Post by the8472 »

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 may be true when accepting input over which the user has control so the library can tell him "do it better".

I would say it's also true for security-related protocols, such as in this case.

But for general network protocols some leniency in processing is necessary, or even beneficial for forwards-compatibility.

Re: OpenSSL Security Advisory

#59

Post by ctz »

valarauca1 wrote: post #55
tomjen3 wrote: post #37

How is it that we still depend on something so broken?

If you think you can write a better implementation then put your hands where your keyboard is. Show us the code. If not, submit patches. An OpenSSL team member said, "If you're in a position to offer technical criticism you're in a position to offer technical help." While it sounds like their pleading for help, its because WE ARE. There are 3 full time maintainers, 1 is a dog :P and only ~10-16 regular patch submitte…

The bit you don't cover is where you repeatedly submit patches (in my case, for example, to fix documentation and improve testing) which are ignored.
Post reply on HN