SSL/TLS passive sniffing

[Anne & Lynn Wheeler]

At 02:53 AM 12/1/2004, Dirk-Willem van Gulik wrote:

> Access to the private key of the server cert gives you the ability to do
> active sniffing and in some subset of cases passive sniffing. Access to
> the session key (which requires the right permissions and access to the
> httpd server) gives you passive sniffing.
>
> It is not uncommon to set this up for customers in the commercial/banking
> sectors to help them comply with certain audit requirements.
>
> Note however that in each case it requires violating the web servers
> security realm and/or storing something in two places. So technically it
> may make much more sense to plug a module into each webserver itself with
> a sufficiently secure agregation backend to accomplish this.


the other attack is on the certification authorities business process 
... crook gets the issuing authority to give them a certificate with all 
the same information ... but their public key; the key-owner may have 
little control over the long term business process standards of the 
issuing certification authority

This is one of the attacks on SSL domain name server certificates.  
Supposedly the purpose for SSL domain name server certificates was some 
perceived vulnerabilities in the domain name infrastructure. Note, 
however, the authoritative agency(s) for domain name ownership is the 
domain name infrastructure. The current process has a SSL domain name 
server certificate applicant supplying some amount of identification 
information. The certification authority then has the error-prone and 
expensive job of contacting the domain name infrastructure 
(authoritative agency for domain name ownership) and comparing the 
supplied identification information (provided with the certificate 
application) with what is on file at the domain name infrastructure.

The attack isn't on the process that was used for the valid applicant 
... the issue is that at any time in the future, can an attacker 
compromise that process .... using any recognized, valid, certification 
authority.

The side note is that the certification authority industry has somewhat 
pushed a business process where the domain name supplies their public 
key to the domain name infrastructure at the time they register the 
domain name. Then when somebody applies for a SSL domain name server 
certificate, they digitally sign the request. The certification 
authority then just has to retrieve the on-file public key from the 
domain name infrastructure and validate the digital signature. This 
turns an expensive and error-prone identification process into a much 
more reliable and less expensive authentication process.

The catch22 of course, is that if the certification authorities can 
retrieve public keys from the domain name infrastructure for 
authentication ... then just about anybody in the world could do the 
same thing .... significantly reducing the need for any SSL domain name 
server certificates.

misc past postings:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
<http://www.garlic.com/%7Elynn/subpubkey.html#sslcerts> 
http://www.garlic.com/~lynn/subpubkey.html#certless

<http://www.garlic.com/%7Elynn/subpubkey.html#certless>

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 
<http://www.garlic.com/%7Elynn/>


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com