On 05-07-2010 15:39, Sebastián Treu wrote:
Hi,
I'm not much related with security, certificates and authentication,
but If anyone can gather our server certificate this way:
echo | openssl s_client -connect ${MY_SERVER}:443 2>&1 | sed -ne
'/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'> mycert.pem
How can we avoid a possible hacked DNS server thats makes a domain
name point to a specific IP and the certificate has been planted in
that server IP, and that server is malicious?
Maybe I'm missing some of the security theory, but if we can use a
fake DNS that resolves a name as we want and also we can gather that
certificate to be installed in the fake-server, how can we resolve
this or what precautions we need to take for this? Is it a kind of
private certificate that we can share?
Best regards,
To impersonate your https server using your certificate, someone will
need TWO things:
A. A copy of your certificate, which your server sends to every client
up front as proof that someone experienced in these matters (the CA)
has verified that you are who the certificate says you are (name,
address etc.)
B. The private key you used when generating the request/order for the
certificate and which matches the public key listed in the certificate.
Unless something is seriously wrong, that private key never leaves your
building and your webserver does not send it to anyone.
The way it works is like this (somewhat simplified!):
1. Someone goes to https://www.yourserver.example
2. Their webbrowser contacts www.yourserver.example and asks for a
secure connection.
3. your webserver sends them a copy of your certificate (A above) and
a list of the secure connection types it can provide
4. Their webbrowser chooses one of the secure connection types (based on
their user settings etc.) and a random secret number
5. Their webbrowser encrypts that secret number with the public key from
the certificate (A above). The crypto math says that it is virtually
impossible to decrypt this without the matching private key (B above)
6. Their webbrowser sends that encrypted number and its choice of secure
connection type to your webserver.
7. Your webserver uses your private key (B above) to decrypt the secret
number, now noone except the user and your webserver knows that secret
number. *A FAKE WEBSERVER COULD NOT DO THAT*
8. The webserver uses the secret number to complete the secure
connection to the users webbrowser.
9. The users webbrowser checks that the secure connection looks ok and
matches the secret number it chose in step 4. The users webbrowser then
concludes that since only it and you could know that secret number, it
is really talking to your webserver and not and imposter, and so it
turns on the green or yellow color and shows a nice padlock to tell the
user that all is A-OK.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
