Re: New Research Suggests That Governments May Fake SSL Certificates

2010-03-26 Thread Jerry Leichter

On Mar 25, 2010, at 8:05 AM, Dave Kleiman wrote:
March 24th, 2010 New Research Suggests That Governments May Fake SSL  
Certificates

Technical Analysis by Seth Schoen 
http://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl

Today two computer security researchers, Christopher Soghoian and  
Sid Stamm, released a draft of a forthcoming research paper in which  
theypresent evidence that certificate authorities (CAs) may be  
cooperating with government agencies to help them spy undetected on  
secure encrypted communications
While the paper provides a nice analysis and description of the  
situation, what surprises me most about it is ... that anyone was  
surprised.  Hardware to support man-in-the-middle splicing of HTTPS  
sessions has been available in the marketplace for several years.   
They are sold by companies like Bluecoat who build appliances to  
monitor incoming and outgoing traffic at the interconnection points  
between corporate networks and the greater Internet.  They're sold as  
means to monitor and control what sites can be accessed (they block  
things like gambling sites, pornography - whatever the corporation  
doesn't want its employees browsing from work) and also inspect the  
data for auditing/information leakage control purposes.


In the corporate environment, where desktops/laptops are managed, the  
way such a device is given the ability to do MitM attacks is  
straightforward:  The corporation simply pushes a new root CA - for a  
CA that actually lives inside the intercept device - into the  
browser's pool.  The device can then generate and sign any certs it  
needs to to wedge into any HTTPS session invisibly.  Even when the  
corporation allows personal machines onto the network, it will often  
require users to accept a corporate CA for access to internal sites.   
Of course, since browsers only have one pool of CA's, once you've  
accepted that CA, you've accepted invisible MitM attacks by the  
monitoring device.


Since the techniques and hardware for doing this has been around for a  
while, it should come as no surprise that someone would notice that  
governments are another good market - in fact, one that tends to be  
fairly price-insensitive.  It's distressing how much government  
intrusion technology is basically relabeled corporate security/ 
compliance technology.


Governments may or may not be in a position to force CA's onto a  
machine, so it would be natural for them to compel existing CA's, as  
the paper rightly points out.

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Against Rekeying

2010-03-26 Thread Perry E. Metzger

Also manually forwarded on behalf of  Peter Gutmann. As  before, if you
reply, don't credit me with the text, it is his.

From pgut001 Fri Mar 26 14:44:54 2010
To: b...@links.org, nicolas.willi...@sun.com
Subject: Re: Against Rekeying
Cc: cryptography@metzdowd.com, pe...@piermont.com, si...@josefsson.org
In-Reply-To: 20100325160755.gf21...@sun.com

Nicolas Williams nicolas.willi...@sun.com writes:

I suspect that what happened, ultimately, is that TLS re-negotiation was an
afterthought, barely mentioned in the TLS 1.2 RFC and barely used, therefore
many experts were simply not conscious enough of its existence to care.

I think that was a significant problem with noticing this, that many
implementors may have looked at it, decided it was a nightmare to implement,
served no really obvious purpose once 40-bit keys had gone the way of the
dodo, and was a significant source of future problems (see my previous
message), and so never bothered with it.  As a result it never got much
attention, as do significant chunks of other security protocols.  I think the
real skill in security protocol implementation isn't knowing what to
implement, but knowing what not to implement (I've had an attack-surface-
reduced SSH draft in preparation for awhile now, I really must get back to the
some time).

One nice thing about being the author of a crypto toolkit is that you can
experiment with this, either skipping features or turning existing features
off in new releases, to see if anyone notices.  If no-one does, you leave them
turned off.  You can turn off an awful lot of security-protocol features
before people start to notice, leading me to believe that a scary portion of
many protocols actually consist of attack surface and not features.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


high speed password cracking on GPUs

2010-03-26 Thread Perry E. Metzger

This is from ten days ago but I just ran across it. Nothing very deep --
just higher speed brute force attacks via GPUs.

http://www.net-security.org/secworld.php?id=9021

-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Against Rekeying

2010-03-26 Thread Nicolas Williams
On Fri, Mar 26, 2010 at 10:22:06AM -0400, Peter Gutmann wrote:
 I missed that in his blog post as well.  An equally big one is the SSHv2
 rekeying fiasco, where for a long time an attempt to rekey across two
 different implementations typically meant drop the connection, and it still
 does for the dozens(?) of SSH implementations outside the mainstream of
 OpenSSH, Putty, ssh.com and a few others, because the procedure is so complex
 and ambiguous that only a few implementations get it right (at one point the
 ssh.com and OpenSSH implementations would detect each other and turn off
 rekeying because of this, for example).  Unfortunately in SSH you're not even
 allowed to ignore rekey requests like you can in TLS, so you're damned if you
 do and damned if you don't [0].

I made much the same point, but just so we're clear, SSHv2 re-keying has
been interoperating widely since 2005.  (I was at Connectathon, and
while the details of Cthon testing are proprietary, I can generalize and
tell you that interop in this area was very good.)

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Against Rekeying

2010-03-26 Thread Peter Gutmann (alt)
Nicolas Williams nicolas.willi...@sun.com writes:

I made much the same point, but just so we're clear, SSHv2 re-keying has been
interoperating widely since 2005.  (I was at Connectathon, and while the
details of Cthon testing are proprietary, I can generalize and tell you that
interop in this area was very good.)

Whose SSH rekeying though?  I follow the support forums for a range of non-
mainstream (i.e. not the usual suspects of OpenSSH, ssh.com, or Putty) SSH
implementations and why does my connection die after an hour with [decryption
error/invalid packet/unrecognised message type/whatever] (all signs of
rekeying issues) is still pretty much an FAQ across them at the current time.

(There's also the mass of ancient copies of the usual suspects, principally
the ssh.com implementation dating back up to ten years, baked into networking
devices and whatnot that will never be updated, or at least if significant
security holes present in the older versions haven't convinced the vendors
using them to update them then I don't think the fact that they drop the
connection after an hour will).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Against Rekeying

2010-03-26 Thread Nicolas Williams
On Sat, Mar 27, 2010 at 12:31:45PM +1300, Peter Gutmann (alt) wrote:
 Nicolas Williams nicolas.willi...@sun.com writes:
 
 I made much the same point, but just so we're clear, SSHv2 re-keying has been
 interoperating widely since 2005.  (I was at Connectathon, and while the
 details of Cthon testing are proprietary, I can generalize and tell you that
 interop in this area was very good.)
 
 Whose SSH rekeying though?  I follow the support forums for a range of non-
 mainstream (i.e. not the usual suspects of OpenSSH, ssh.com, or Putty) SSH
 implementations and why does my connection die after an hour with [decryption
 error/invalid packet/unrecognised message type/whatever] (all signs of
 rekeying issues) is still pretty much an FAQ across them at the current time.

Several key ones, including SunSSH.  I'd have to go ask permission in
order to disclose, since Connectathon results are private, IIRC.  Also,
it's been five years, so some of the information has fallen off my
cache.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com