Re: [TLS] Heartbleed / protocol complexity

[Patrick Pelletier <[e-mail]>]

On 4/10/14, 7:24 PM, Watson Ladd wrote:

> Systematically ensuring that all invalid length combinations would
> have triggered an error would have worked. That's more than some test
> vectors. Furthermore, it's not clear how you supply test vectors to a
> protocol implementation: it can be done, and should be, but it is
> quite a bit of work.

Presumably in the form of a pathological client (or server) that sends 
nasty things to its peer, and checks how it responds to them.  Although 
it would be a lot of work, I think the first step would just be 
establishing such a test suite that could be used by all TLS 
implementations, and then many could contribute to it over time.

> What could have mitigated this bug would be not disabling OS
> protection measures in malloc. Had OpenSSL not used their own malloc,
> then on OpenBSD the malloc flags "FGJZ" would have significantly
> reduced the impact of the attack, and quite possibly crashed the
> process if exploitation was tried. (OpenSSL has bugs that are only
> found when you disable their own malloc wrapper, which is why they
> didn't do it).

Can you elaborate on this, or point me to a place where it has been 
discussed before?  Although crypto/mem.c is complicated enough that I 
could easily be missing something, I thought that by default, 
CRYPTO_malloc essentially just wraps the system malloc.  How does this 
wrapper make the system malloc behave any differently?

> Various proposals for taint analysis in C have floated around for a
> number of years. However, qmail demonstrates that one can write secure
> C code without this assistance.

One *can* write secure code in any language, but it's a question of ease 
and probability.  Even though DJB can write secure C code, I'm of the 
opinion that on the whole we'd be a lot better off if security-critical 
code was written in a memory-safe language.

> Furthermore, there was no need to implement heartbeats over TLS for
> web servers.

Yes.  It seems like TLS/DTLS could benefit from "profiles" indicating 
which features are recommended for which uses.  There could be a "web 
profile", a "mail profile", an "Internet of Things" profile. etc.

> However, the fundamental problem isn't anything more than the
> developers of OpenSSL being lackadaisical about security.

I'm inclined to agree with you, but to be a bit more charitable and 
specific, I think the problem boils down to two main things:

1) Lack of process.  It's unclear who's in charge of OpenSSL, how they 
decide what features to put in or leave out, when they decide to fix 
bugs, and so forth.  Bugs often languish in the bug tracker, without 
ever being marked "yes, we will fix this" or "no, we won't."  For an 
outsider, it's unclear how to become involved in OpenSSL in a 
constructive way, since there seems to be a lack of structure, and 
almost a certain hostility to outsiders.

2) Trying to be all things to all people.  OpenSSL is a huge, 
general-purpose cryptography library, of which TLS is only a part, 
despite the name.  Besides having the kitchen sink, feature-wise, it 
also tries to be extremely portable.  Supporting obscure, obsolete, or 
embedded operating systems means the code is much more complicated than 
it needs to be to support typical use on mainstream desktop and server 
operating systems.  Not to mention that a lot of code is doubled due to 
the FIPS versus non-FIPS distinction.

> miTLS does a much better job, is in a
> high level language, costs 10x as much in computation time, and is
> guaranteed to be correct.

Yes, miTLS seems very tantalizing; it seems like it ought to be used 
more.  (Although I shouldn't be one to talk, since I'm using OpenSSL in 
my project at work, despite all of its horribleness.)

--Patrick