amuck-landowner

CEO/Founder of CloudFlare thinks HTTPS is over UDP

KuJoe

Well-Known Member
Verified Provider
Originally I was defending him because his non-technical background entitles him to make mistakes in a field he is not familiar with. Now I'm defending him because he was repeating something about the Heartbleed bug from the person who discovered the Heartbleed bug so the people attacking somebody for repeating something somebody else said is illogical.
 

Exelion

New Member
Originally I was defending him because his non-technical background entitles him to make mistakes in a field he is not familiar with. Now I'm defending him because he was repeating something about the Heartbleed bug from the person who discovered the Heartbleed bug so the people attacking somebody for repeating something somebody else said is illogical.
If he did repeat it, he repeated it in a way that shown he didn't completely understand it.
 

tchen

New Member
Prince actually repeated it quite concisely albeit bluntly to someone who assumed wrongly that heartbleed was strictly a TCP/HTTPS vulnerability.  Lyon's refusal to admit his own mistake and then subsequently bark up/redirect the discussion to the certificate amp protection in DTLS (the cookie bit) is a bit sad.  RFC 6347 adds that security feature for handshaking, but sadly RFC 6520 is slightly orthogonal to it, with only passing mention to the 6347.  As it currently is, OpenSSL's implementation of heartbeat is outside the handshake, as the original patch mentions "Heartbeats can be sent any time when no handshake is in progress to check the availability of the peer"

In fact, most network IDS setups right now purporting to monitor for heartbleed attacks relies on the fact that most malware implementations right now bypass the handshake altogether and go directly for the jugular (hence why you can 'detect' it unencrypted).

In the end, Mr. Mehta is right.  Fix your DTLS apps too.

Please.
 

Exelion

New Member
Prince actually repeated it quite concisely albeit bluntly to someone who assumed wrongly that heartbleed was strictly a TCP/HTTPS vulnerability.  Lyon's refusal to admit his own mistake and then subsequently bark up/redirect the discussion to the certificate amp protection in DTLS (the cookie bit) is a bit sad.  RFC 6347 adds that security feature for handshaking, but sadly RFC 6520 is slightly orthogonal to it, with only passing mention to the 6347.  As it currently is, OpenSSL's implementation of heartbeat is outside the handshake, as the original patch mentions "Heartbeats can be sent any time when no handshake is in progress to check the availability of the peer"

In fact, most network IDS setups right now purporting to monitor for heartbleed attacks relies on the fact that most malware implementations right now bypass the handshake altogether and go directly for the jugular (hence why you can 'detect' it unencrypted).

In the end, Mr. Mehta is right.  Fix your DTLS apps too.

Please.
Maybe the twitter conversation is out of context, but I don't see him actually saying this is DTLS related, which yes, DTLS is affected by this since afaict it also allows heartbeat and thus has to be fixed too. That is a correct analysis. But from the twitter conversation I see, I see no indication this was about DTLS.
 
Last edited by a moderator:
Top
amuck-landowner