[gnutls-devel] disabling SSL 3.0 by default in 3.4.0

[Peter Williams]

last email, on a non topic.


Why the “rush” now  - when there was no imperative last month to disable sslv3 (when the same class of attack on steam based cbc-modes existed, same traffic levels (almost zero), same level of noted web-exploitation (none))? Answer! Because cybercommand is calling the shots, and running a drill!


anyway, its good that folk know generally realize that certain US defense and national security vendors (or their civilian proxies), who contributed to SSL v3 20 years ago, did so with FULL KNOWLEDGE of what they were doing.


One should assume it goes on today, with the same intensity - doing whatever it takes to subvert commodity-upgrade crypto at the design or more likely the implementation level. And that starts with subverting the leadership folk (what’s new!)


One might wish to chat to cisco engineers, who were “required” to alter the router’s key management protocol, which consisted of layered signed and encrypted PKCS7 APDUs, over ssl v3 for anti-replay; for a good case study of crypto subversion using cbc-exploits similar to those “suddenly” used against ssl v3. What’s worse, “for compatibility”, it now comes with WINDOWS SERVER… Of course, one REALLY wants it applied to key management (vs. cat picture downloading). If you go log searching for historical exploit evidence, start there (not on cat downloading sites).


But, now I’m preaching on CBC, so I stop.  Its all “commodity crypto”, and thus a toy to make folk feel good.



Sent from Windows Mail





From: Tim Rühsen
Sent: ‎Thursday‎, ‎October‎ ‎16‎, ‎2014 ‎3‎:‎35‎ ‎AM
To: gnutls-devel at gnu.org
Cc: peter Msn, Daniel Kahn Gillmor, GnuTLS development list





Am Mittwoch, 15. Oktober 2014, 22:50:26 schrieb Peter Williams:
> Folks are “Rushing” because, last week, this was not even on the radar -
> even though the use of standards committees to engineer-in cbc mode oracle
> attacks has been going on for 20 years. Same goes for the packet drivers
> and their careful reaction to inbound bit patterns that changes the code
> path takes, that then play the role of the JavaScript “in the latest cbc
> mode oracle attack”.

It's time to rush because the threat just became *real*.
We (developers/coders) can't do much on 'unknown' threats.

 
> And so it continues (in this or other guise). Strange that folks just WONT
> handshake, at the end of APDU exchange (since it has so little cost, 20
> years on)
 
> 
> Don't really know what to recommend, when the “trustworthy” technical
> standards forums (IETF) or their review processes (IESG) are themselves
> fundamentally untrustworthy, in any crypto matter. Everyone knows US
> delegation to ISO/ITU-T was always an arm of dept of state (and woe betide
> anyone expenses payment, if you stepped out of line…)
 
> 
> I asked Steve Kent once, exempting a French official report on the crash of
> a Russian jet at an air show (due to French spying) - why the report should
> be trusted - since it was an obvious cover up (and actively misrepresented
> culpability concerning deaths in the crowd).. His answer was - that
> “official trust” exists to be manipulated - when one is dealing with
> national security issues. The “investment” in standards was there to
> project such trust attacks, and engineer an deception-friendly environment,
> focused on human weakness, consumer or admin (or crypto officer) alike.
 
Lies everywhere ;-) You simple can't distinguish between a lie and the truth. 
So I simply can't take *anything* of this into my calculations.

However, if your conclusion is 'not to rush'... how long should we wait before 
you don't call it 'rushing' any more ? What is your plan ? Firing FUD and tell 
people to sit and wait ? Hmm, maybe I got something wrong... but I can't find 
anything *useful* within your writing, sorry.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141016/137ac723/attachment.html>