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 [EMAIL PROTECTED]
