[VOIPSEC] Governments employing MiTM attacks against SSL

[T Biehn]

Disgusting:
# If you have zero to hide, you have zero to worry about. The logical
# truth is, so much data need be sifted through, unless - again - you had
# something to hide, the odds of the government using YOUR data from a
# MITM attack is highly unlikely.

And obviously you didn't consider the possible attack scenarios very deeply.

-Travis

On Tue, Apr 13, 2010 at 2:48 PM, J. Oquendo <sil at infiltrated.net> wrote:
> Ronald del Rosario wrote:
>
>> > VoIPSA readers,
>> >
>> >
>> >
>> > I would like to get your opinion regarding Christopher Soghoian and Sid
>> > Stamm's recently release Proof of Concept (PoC) paper "Certified Lies:
>> > Detecting and Defeating Government Interception Attacks Against SSL
>> > <http://files.cloudprivacy.net/ssl-mitm.pdf> ".
>> >
>> >
>> >
>> >
>>
>
> This attack/technique and or concept isn't anything new. In fact, I can
> point back to 1999 - 2000 when *someone* started a rumor about an agency
> having this capability. Back then (for those who remember) it would have
> been "gibberish" to flat out say: "Well... They're doing this!" because
> the "security" world would have asked for definitive proof outside of a
> *rumor* ...zzzzz Zorro(and other "rumors) were well-known - theories.
> Bottom line... Deal with it. Seriously.
>
> Even if you attempted to be vigilant about EVERY connection you could
> make. Do you honestly and sincerely believe you will be opening
> (manually) every single cert when you visit an HTTPS enabled site? How
> long before you get tired. Even if you did, netsed is a PITA. Do you
> honestly think you could avoid this. You could theoretically try...
> Tunnel into one machine, into another into another... How long before
> you get tired?
>
> If you have zero to hide, you have zero to worry about. The logical
> truth is, so much data need be sifted through, unless - again - you had
> something to hide, the odds of the government using YOUR data from a
> MITM attack is highly unlikely. In fact, you could probably hit the
> Powerball in every state before your data made even a blip on the radar.
>
>
>> > I understand CALEA, but when a government can easily fool an end-user by
>> > employing a MiTM method and present a fake signed Digital Certificate
>> > for its own purpose, how can we accelerate the adoption of Cloud
>> > Computing and VoIP in the industry and build trust when more and more
>> > news describing how flawed the underlying technology designed to protect
>> > their transaction is being bypassed?
>> >
>> >
>>
>
> What does this have to do with cloud computing exactly? The worst thing
> you could seriously ask for as a fix in any case, is to place your trust
> on a cloud services provider. It goes right back to the core of this
> message... MITM. Do you think for a second that under a National
> Security Letter a cloud provider wouldn't do the same?
>
> As for fixes... There was some work done to defend against MITM (SRP
> (RFC2945), SPEKE, 1363 (http://grouper.ieee.org/groups/1363/)) but the
> general public doesn't want secure (seriously). They want it fast...
> Right now... "What the heck is this password?! Stupid machine... I'll
> make the password: drowssap no one will ever guess!" or "BofA... Oh look
> a picture of a guitar... I'll make my sitekey Gibson!... No one will
> ever know!" No matter what you personally think, superlargemegaco's have
> to cater to the majority. And the majority say: "Huh? What is this
> certificate error message?... Oh well I don't know I guess I'll accept!"
>
> No matter what you would like, the honest/realistic answer is... 1)
> Cloud Security is as secure as you giving me your machine... Even if I
> were say your best friend, doesn't mean I'm competent. Therefore when it
> comes to security, its better to take care of your own security... You
> have more to lose than a cloud provider... 2) There are fixes for MITM
> ... Don't hold your breathe on it. Plenty of certificate generating
> monopolies with deep pockets for lobbying abound. 3) If you have nothing
> to worry about... Why bother making noise?
>
> Lastly... Unless you are your own carrier, own your own network (pipes
> and all...) There is no way you can stop something like Naurus or Packet
> Forensics... Besides, unless you actually took the time to READ PF's
> data about the five series, you shouldn't worry: "users have the ability
> to import a copy of any legitimate key they obtain legally - or they can
> generate their own look-a-like keys" ... Translation: Either the gets a
> hold of a valid cert (which in that case, no special device is really
> needed anway) OR they create a fake cert and a user (as stated above)
> says: "What the! Who! What is this certificate warning?! Better press
> ok, I need to do my banking fast!"
>
>
>
> -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J.
> Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a
> reputation and five minutes to ruin it. If you think about that, you'll
> do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771
> 1DCE 1FD1 5CCD 6B5E
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>



-- 
FD1D E574 6CAB 2FAF 2921  F22E B8B7 9D0D 99FF A73C
http://pgp.mit.edu:11371/pks/lookup?search=tbiehn&op=index&fingerprint=on
http://pastebin.com/f6fd606da