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

Qualys Security Advisory – LibreSSL

seclists.org

Post reply on HN
Print view View original

71–80 of 89 posts

Re: Qualys Security Advisory – LibreSSL

#71

Post by MichaelGG »

alricb wrote: post #58
masklinn wrote: post #13

Earlier quoted context omitted.

Is it TLS specifically or X509 (both by itself and because it uses ASN.1)? I dimly remember X509 and ASN.1 being commonly criticised for their complexity, does TLS pile on additional complexity or just inherit it?

In this case it's definitely ASN.1; the problem is that "objects" are defined with OIDs, which are sequences of integers (called arcs numbers) like { 1 2 840 113549 1 }. The first integer is always 0, 1 or 2, and with 0 or 1, the second is between 0 and 39. But the other integers can be arbitrarily large, and it's important not to overflow: https://www.viathinksoft.de/~daniel-marschall/asn.1/oid_fact... You need to u…

Why does ASN.1 allow such large arc numbers? Is this a result of being designed before a reasonable (32 bit) word size was common enough to depend on? Ie that everyone would have to implement "bignum" so might as well set no limit?

It still seems questionable that they'd let any length be set, especially since you can just chain numbers together into a longer OID.

Base128 encoding seems fair though; the other varint formats are more exotic and only work with many ints at once.

Re: Qualys Security Advisory – LibreSSL

#72

Post by byuu »

riffraff wrote: post #34
byuu wrote: post #16

Earlier quoted context omitted.

> the library is written in a language with manual memory management and unsafe memory access. C's simplicity is certainly a blessing and a curse. Right now, I'm of the opinion that C++ is the best we've got, even if not perfectly ideal. RAII, shared pointers and smart containers with bounds checking allows you to keep nearly all of the performance without the drastic downsides of tracing garbage collectors (obscene…

> And when you get into the really high-level languages (Python, Ruby), they simply don't scale. I think you need to qualify what "scale" means in this context. Otherwise java is, for all its warts, more or less as high level as ruby and python, and it's probably been proven to scale up (to big machines, or many developers) reasonably well.

Just as a random example:

https://www.reddit.com/r/programming/comments/3p6r2v/i_wrote...

I've constantly had similar experiences. I tried to write the GUI portion of my programs with Python and PyGTK. I needed to write a simple function that scaled up a bitmap from 256x224 to 512x448. A nearest-neighbor pixel doubler with no interpolation, color conversion, or anything else. It ended up running at around 30fps with nothing but the scaling, on a Core i7-2600k processor. And when I asked for help in optimizing it, nobody could really improve the Python, and they recommended I write "the slow parts" in C as a shared library, and invoke that from the Python GUI.

It's okay to be 10%, 30% or even 50% slower than C. But to be 2500% slower or more is completely unacceptable for production code. That level of performance only works on websites with small amounts of traffic, or on the simplest of applications.

The root problem here is of course dynamic typing. That makes scaling both performance and code size much more challenging.

Java is certainly vastly better, but the garbage collection and its stalls, wasteful memory usage (I've seen our production servers bog down with Tomcat eating up all the RAM on the server for simple programs), and overall extreme negatives of the language itself (no unsigned integers, limited to single inheritance, terrible support for generics [maybe this has changed recently?], etc), plus the legal issues that Oracle is saddling the language with, make it an unacceptable alternative.

C# might have been better if Microsoft ever cared about any platform other than Windows.

Both dynamic typing and garbage collection are the wrong ways to solve the problems of C. Rust is the closest I've seen to addressing the real problems, but it coming from Mozilla (with their terrible record with Firefox), and the syntax being so radically different from C, I think will chase a lot of people off.

Re: Qualys Security Advisory – LibreSSL

#73

Post by acveilleux »

0x01 wrote: post #51
masklinn wrote: post #49

Earlier quoted context omitted.

Well for a start lua not having integers would be an issue when implementing cryptographic primitives. The second issue is while lua is relatively lightweight, carrying a full lua runtime for each of the libraries you're using would still get unwieldy and costly, adding ~400K to each embedder according to the About page ("Under 64-bit Linux, […] the Lua library takes 414K")

Apologies. I should have referenced Lua 5.3 instead as it has both integer and bitwise operator support. This should satisfy the concerns regarding crypto implementation. As for the space considerations, I have two ways to reason this: * Wouldn't it only take up 1x414K? If you create luaSSL as a drop in replacement to OpenSSL, you'd only need one copy in your filesystem, just as you only have one OpenSSL. * Even if y…

For crypto-primitives, you usually want them to be constant-time. This is basically impossible to do in an interpreter or a JIT, indeed optimizing compilers can and will optimize contant-time operations out so inline assembly is commonly used.

Re: Qualys Security Advisory – LibreSSL

#74

Post by byuu »

Phemist wrote: post #44
quonn wrote: post #10

Earlier quoted context omitted.

> Complexity breeds these kinds of problems as a natural consequence. But the bugs described are not complex - they are local problems that can be understood by just reading one function. The problem here is not complexity, but size (not enough people spend enough time to review all of the code) and the fact that the library is written in a language with manual memory management and unsafe memory access. > I do know…

As far as http+integrity goes: Integrity checks are also based on a shared secret, see https://en.wikipedia.org/wiki/Hash-based_message_authenticat... . So for http+integrity, without the secrecy aspect of TLS, ie the hmac key being public, it would be trivial to generate your own valid integrity hash.

I'm not the right person to design the entire system, obviously. But as a starting point, I'd consider using a PGP signing key on responses from a server. Your keys would be hosted on an HTTPS server somewhere. Let's say httpi.org or something.

signify also looks really promising. Get the key down to the size of a QR code, and you could separate the issue of signing from signature validation entirely ... post it on your HTTPS Twitter feed, put it on your business card, whatever.

I think it would be a positive step to get users to think about how they are verifying integrity themselves and the sources they trust.

You could even have a dozen sources and let there be a little button in the URL bar to show you which sources agree on a public key provided by a server.

Re: Qualys Security Advisory – LibreSSL

#75

Post by masklinn »

MichaelGG wrote: post #71
alricb wrote: post #58

Earlier quoted context omitted.

In this case it's definitely ASN.1; the problem is that "objects" are defined with OIDs, which are sequences of integers (called arcs numbers) like { 1 2 840 113549 1 }. The first integer is always 0, 1 or 2, and with 0 or 1, the second is between 0 and 39. But the other integers can be arbitrarily large, and it's important not to overflow: https://www.viathinksoft.de/~daniel-marschall/asn.1/oid_fact... You need to u…

Why does ASN.1 allow such large arc numbers? Is this a result of being designed before a reasonable (32 bit) word size was common enough to depend on? Ie that everyone would have to implement "bignum" so might as well set no limit? It still seems questionable that they'd let any length be set, especially since you can just chain numbers together into a longer OID. Base128 encoding seems fair though; the other varint…

> Why does ASN.1 allow such large arc numbers? Is this a result of being designed before a reasonable (32 bit) word size was common enough to depend on? Ie that everyone would have to implement "bignum" so might as well set no limit?

I assume that's because OID nodes are essentially namespaces, giving an arbitrary upper bound to node ids would artificially and "unnecessarily" limit the size of the corresponding namespace. That looks like a "correct versus realistic" debate which was won by the "correct" side.

Re: Qualys Security Advisory – LibreSSL

#76

Post by masklinn »

AUmrysh wrote: post #69
xorcist wrote: post #31

Earlier quoted context omitted.

Most languages use unconditional jumps to break flow when necessary, it might be called "exception" instead of "goto" but it's conceptually the same thing.

In many high level languages a break, continue, pass, that sort of thing (where you want to skip or escape a loop iteration) is usually implemented with a goto as well. Also, a common use of goto in C is when you're doing something in nested for loops and want to break out of all of them. A goto is actually much cleaner here than using sentinel values or boolean flags, or naughty things like setting your loop variabl…

Well if you go that way, fundamentally all structured programming techniques are implemented with a goto, that's what jumps are.

Re: Qualys Security Advisory – LibreSSL

#77

Post by dguido »

IgorPartola wrote: post #65

Here we go. Another round of "damn it, it's written in C. that's the root of all evil". I think by this point a Markov chain can easily generate responses to the OpenSSL/LibreSSL vulnerability announcements so we don't have to. Yes, C sucks because buffer overflows are still possible. That's by design. At the same time, it goes something like this: 1. OpenSSL (or this time LibreSSL) has a vulnerability discovered. 2.…

Don't forget these functional alternatives to OpenSSL:

1. OCaml-TLS (https://github.com/mirleft/ocaml-tls) [1]

2. miTLS (http://www.mitls.org/wsgi/home)

3. s2n (https://github.com/awslabs/s2n)

[1] Home of the epic Bitcoin Pinata! http://ownme.ipredator.se/

Re: Qualys Security Advisory – LibreSSL

#78

Post by briansmith »

IgorPartola wrote: post #65

Here we go. Another round of "damn it, it's written in C. that's the root of all evil". I think by this point a Markov chain can easily generate responses to the OpenSSL/LibreSSL vulnerability announcements so we don't have to. Yes, C sucks because buffer overflows are still possible. That's by design. At the same time, it goes something like this: 1. OpenSSL (or this time LibreSSL) has a vulnerability discovered. 2.…

> 5. People poo poo any alternative to OpenSSL because it's not 100% feature complete and besides the best crypto people are already working on OpenSSL so what do these schmucks know?

Here's a strategy:

Take OpenSSL, remove a bunch of stuff that almost nobody needs, rearrange the code to make it clearer. You will get BoringSSL.

Take the BoringSSL code, remove more stuff that people outside of Google generally don't need. Temporarily remove the X.509 code and the TLS code so that you can remove even more stuff.

Next, write bindings for the remaining code for a safe language like Rust, so that the replacement X.509 and TLS code can be written in the safer language, while still using the OpenSSL crypto code.

Then, write the new X.509 code, focusing on what really is needed and ignoring all the extra cruft that was added to X.509 but which doesn't actually improve security.

Then, over time, refactor the the language bindings so more code is written in the safe language and less code is written in C, with the goal of almost all the code that isn't implementing directly crypto algorithms being in the safe language.

Then, add a good, clean TLS implementation in the safe language, that focuses on the good parts of TLS, and that avoids all the legacy cruft that makes TLS seem complicated.

I've been doing an experiment along these lines. I've open sourced two parts so far:

1. https://github.com/briansmith/ring 2. https://github.com/briansmith/webpki

It is a big project, but I am pretty sure it is going to succeed.

Re: Qualys Security Advisory – LibreSSL

#79

Post by briansmith »

IgorPartola wrote: post #65

Here we go. Another round of "damn it, it's written in C. that's the root of all evil". I think by this point a Markov chain can easily generate responses to the OpenSSL/LibreSSL vulnerability announcements so we don't have to. Yes, C sucks because buffer overflows are still possible. That's by design. At the same time, it goes something like this: 1. OpenSSL (or this time LibreSSL) has a vulnerability discovered. 2.…

> 6. Someone points out that in higher level languages it's hard to write code that is resistant against timing attacks. The discussion dies.

This doesn't matter, because the code that should be resistant to timing attacks should be written in assembly language or a language specially designed for that purpose (that doesn't exist yet) anyway. High-level languages have ways of accessing code written in assembly language.

Anyway, my point is that all these things are solvable.

Re: Qualys Security Advisory – LibreSSL

#80

Post by heinrich5991 »

briansmith wrote: post #79
IgorPartola wrote: post #65

Here we go. Another round of "damn it, it's written in C. that's the root of all evil". I think by this point a Markov chain can easily generate responses to the OpenSSL/LibreSSL vulnerability announcements so we don't have to. Yes, C sucks because buffer overflows are still possible. That's by design. At the same time, it goes something like this: 1. OpenSSL (or this time LibreSSL) has a vulnerability discovered. 2.…

> 6. Someone points out that in higher level languages it's hard to write code that is resistant against timing attacks. The discussion dies. This doesn't matter, because the code that should be resistant to timing attacks should be written in assembly language or a language specially designed for that purpose (that doesn't exist yet) anyway. High-level languages have ways of accessing code written in assembly langua…

Rust has some compiler plugin magic that can help you write code resistant to timing attacks.
Post reply on HN