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

RFC 6520 and the OpenSSL Heartbleed bug share the same author

news.ycombinator.com

Post reply on HN
Print view View original

11–13 of 13 posts

Re: RFC 6520 and the OpenSSL Heartbleed bug share the same author

#11

Post by ebyrob »

tptacek wrote: post #4

The payload in RFC 6520 serves a clear purpose, one discussed in the open on the TLS WG mailing list, which you should probably read before casting stones. To wit: TLS Heartbeats were originally intended for DTLS (in fact, the first draft was apparently DTLS-specific). Datagram protocols have a problem: if datagrams are too large, the IP protocol will need to fragment them. Fragmentation is calamitous for performance…

> It's not a good protocol.

I think you said it yourself. So why argue when it's pointed out?

Clearly path discovery has nothing to do with keeping a connection open. Further, can't path discovery be done in an un-encrypted TCP or UDP channel with separate tooling and the results passed into tuning parameters of the encrypted protocol? (This is even assuming the security layer on top of TCP even needs to know MTU when TCP is handling it already)

Since when is THE secure protocol supposed to be the kitchen sink dumping ground of the internet?

Re: RFC 6520 and the OpenSSL Heartbleed bug share the same author

#12

Post by ebyrob »

bjourne wrote: post #3

It's better to yourself get involved in drafting the rfc:s, if that is your thing, rather than throwing out insane accusations.

Microsoft taught us all to "Never attribute to malice...".

However, after reading the related RFC I've rarely seen such over-designed garbage. I'll be amazed if OpenSSL is the only implementation with a heartbeat exploit.

As to the implementation. It just makes me queasy to see a callback before any validation code (bounds checking). It's still that way in the latest fix. I physically can't get past that to even ponder the rest.

At least the new comment has the right idea:

/* Read type and payload length first /

Unfortunately... It's definitely not first.

> If the payload_length of a received HeartbeatMessage > is too large, the received HeartbeatMessage MUST be > discarded silently.

Wow, on so many levels just wow. Terminate the connection forcibly anyone? return ALL_HELL_BROKE_LOOSE & YOURE_UNDER_ATTACK? No, guess that's not helpful here...

/ Read type and payload length first (now w/accuracy / if (1 + 2 + 16 > s->s3->rrec.length) for( int borken = 0;;) return 1 / borken;

if (s->msg_callback) ...

There, fixed that for ya.

Yet, there's ANOTHER line that stops me cold:

unsigned char p = &s->s3->rrec.data[0], *pl;

I don't suppose s or s3 could EVER be NULL? Of course, USUALLY that would just cause some kind of app crash...

Re: RFC 6520 and the OpenSSL Heartbleed bug share the same author

#13

Post by ebyrob »

ebyrob wrote: post #12
bjourne wrote: post #3

It's better to yourself get involved in drafting the rfc:s, if that is your thing, rather than throwing out insane accusations.

Microsoft taught us all to "Never attribute to malice...". However, after reading the related RFC I've rarely seen such over-designed garbage. I'll be amazed if OpenSSL is the only implementation with a heartbeat exploit. As to the implementation. It just makes me queasy to see a callback before any validation code (bounds checking). It's still that way in the latest fix. I physically can't get past that to even pond…

Ugh, formatting.

Note: It's very obvious the validation code is in the wrong spot. However, after looking at it? It's so unclear what is going on in the validation code that I'd have to spend some time to detangle it.

Post reply on HN