Re: SSL questions
From: Anne & Lynn Wheeler (lynn@garlic.com)
Date: 02/27/03
- Next message: Anne & Lynn Wheeler: "Re: SSL questions"
- Previous message: lurker: "Re: Using GPS data to secure fiber/ethernet"
- In reply to: Punkroy: "Re: SSL questions"
- Next in thread: Anne & Lynn Wheeler: "Re: SSL questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Anne & Lynn Wheeler <lynn@garlic.com> Date: Thu, 27 Feb 2003 21:46:48 GMT
PunkroyREMOVETHIS@DrQue.net (Punkroy) writes:
> So that I am clear in what many seem to be saying: If anyone
> compromises the server certificate, all communications that used that
> certificate CAN be decoded. Is that correct?
> If so, am I the only one who feel that is a rather large open door
> for all those e-commerce sites. A disgruntled employ gets access to
> the server certificate and could decrypt any session that certificate
> was used for?
> Okay, but the certificate still has a password on the private key,
> right? But I've read server certificate can be stored without the
> private key encrypted. In the setup I did, I read about this option
> so you didn't have to enter a password when the webserver first
> started. Anyone have an idea of how many admins don't encrypt the
> certificate private key?
>
> For some reason, I had always thought the certificate was used only
> for authentication and that both the server and client would generate
> a temporary key set used to encrypt traffic only for that session.
> After the session was complete, the key sets were discarded and the
> data they sent back can not be decrypted by anyone-- including the
> original sender and receiver (less bruteforce attack on session key,
> factoring public key, ect). If that is not the case, why? I thought
> about the possibility of speed being an issue-- but the client has to
> generate a keyset. True, the server might be doing hundreds of
> connections at once, but is the trade off really worth the risk? Is
> there a system like the one I've outlined above already in SSL? If
> so, please give me a link-- that is what I am interested in using.
>
> Since I am on the subject of server certificates, I might as well
> ask this question as well: Does the root authority who signs a server
> certificate ever get the private key? It seems this question should
> also be a "no" answer, but after learning more about certificates from
> this thread, I'm not sure I trust anything done by SSL.
if you know somebody's public key .... you can encrypt stuff with that
public key and only the entity with the corresponding private key can
decrypt it. various protocols generate a random secret key ... encrypt
the secret key with the public key and then encrypt the actual data
with the secret key. only the entity with the corresponding private
key can recover the secret key and then decrypt the rest of the
message.
the certificate isn't held under password look & key ... the private
key is suppose to be held in some sort of protective control. a
certificate is some digitally signed information that effectively
creates a trusted binding between some pieces of information and a
public key.
for ssl server certificates there is the complex chain of processes to
1) provide for privacy of data (aka encryption) and 2) validate that
the entity you are communicating with is really that entity.
browsers have tables of trusted (CA, certification authority) public
keys. CAs are responsible for validating associations between domain
names and public keys ... and creating digital signed certificates
that assert the binding between a domain name and a public key. the
integrity of the certificate is validated by using one of the CA
public keys to confirm the CA's digital signature (on certificates).
browsers that have validated the integrity of the certificate also
check that the URL that somebody typed in has a domain name that
matches that in the certifcate ... that establishes the equivalence
between the domain name and a public key.
the browser generates a random secret key, encrypts some data with the
random secret key, encryptes the random secret key with the public
key. given
1) the validity of a certificate,
2) the equivalence between the typed in URL and the domain name in the
certificate
3) the certificate's domain name and the certificate's public public
key,
4) the encryption of the random secret key with the public key
5) the encryption of the data with the random secret key
then the assumption is that only the web server in the original typed
in URL can decrypt the data (since only that web server has the
private key that can recover the random secret key).
a big reason for all of this infrastructure is a concern regarding the
integrity of the domain name infrastructure's ability to provide
trusted serving up of domain name to ip-address mapping (aka a
compromise of the domain name infrastructure so that traffic is routed
to a fraudulent ip-address).
a problem is that the authoritative agency for domain names is the
domain name infrastructure .... nominally certification authorities
aren't the actual agency responsible for the information they are
certifying .... they must corroborate the information in a certificate
application with the authoritative agency ... in the case of domain
names, is the domain name infrastructure ... aka the certification
authorities (for ssl server domain name certificates) are dependent on
the very same infrastructure that everybody has integrity concerns
about.
so there have been some suggestions (somewhat prompted by
certification authorities) about how to improve the integrity
(vulnerabilities) of the domain name infrastructure. a catch-22 is
that if the integrity of the domain name infrastructure is improved
for the certification authorities ... it is also improved for
everybody (somewhat mitigating the concern about its integrity and the
original justification for having ssl certificates).
lots of past discussion:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
-- Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/ Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
- Next message: Anne & Lynn Wheeler: "Re: SSL questions"
- Previous message: lurker: "Re: Using GPS data to secure fiber/ethernet"
- In reply to: Punkroy: "Re: SSL questions"
- Next in thread: Anne & Lynn Wheeler: "Re: SSL questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
