|
Posted by Gonzo on December 22, 2006, 7:06 am
If you were Registered and logged in, you could reply and use other advanced thread options
Hello everyone,
This may be very obvious, but I would love to hear a clear explanation.
Let's say I configure a web server with HTTPS only. Then I issue a
couple of queries from a browser, while I sniff all the traffic out to
a file (even though is is encrypted). Finally, I hand you the sniffed
traffic AND the server certificate file (cert file, key file, even the
key phrase or password). Questions:
1. Can the sniffed traffic be decrypted, at least in theory, with all
the information in the scenario I am posing? My guess is "yes",
although I am not sure how to go about it.
2. If the traffic can be decrypted, is this a time consuming process,
or a pretty quick thing? Perhaps it is even trivially scriptable?
Thanks for any information and comments. Best regards.
Gonzalo Diethelm
|
|
Posted by MC on December 22, 2006, 6:25 pm
If you were Registered and logged in, you could reply and use other advanced thread options
Dear Gonzalo,
Gonzo wrote:
> This may be very obvious, but I would love to hear a clear explanation.
>
> Let's say I configure a web server with HTTPS only. Then I issue a
> couple of queries from a browser, while I sniff all the traffic out to
> a file (even though is is encrypted). Finally, I hand you the sniffed
> traffic AND the server certificate file (cert file, key file, even the
> key phrase or password). Questions:
>
> 1. Can the sniffed traffic be decrypted, at least in theory, with all
> the information in the scenario I am posing? My guess is "yes",
> although I am not sure how to go about it.
If you are given the private key as well, of course it can be decrypted.
That is the whole point of keeping private keys private :)
With HTTPS, first a handshake is done, and a unique session key is
established next to the exchange of public parts of the certificates
used. The encryption like any asymmetrical method, relies on a
sufficiently large encryption key based on all this data, that can be
decrypted by the client (web browser) quickly since the private part of
the key needed is known to the client.
More information on how HTTPS works can be found online easily.
> 2. If the traffic can be decrypted, is this a time consuming process,
> or a pretty quick thing? Perhaps it is even trivially scriptable?
In theory, every encrypted data stream can be decrypted given enough
time. That is why browsers quite quickly moved from 56-bit to 128-bit
encryption after the more widespread introduction of using SSL. It is,
even with "low-grade" encryption, still a time consuming process since
the way to find the right key would be to brute-force the private key to
decipher the data. For normal web use, 128-bits is quite sufficient but
like I said given enough time that can also be broken and decrypted. Not
easily though, and not simply by scripting something to run over a
captured stream.
HTH
|
|
Posted by Gonzo on December 22, 2006, 11:29 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> If you are given the private key as well, of course it can be decrypted.
> That is the whole point of keeping private keys private :)
> With HTTPS, first a handshake is done, and a unique session key is
> established next to the exchange of public parts of the certificates
> used. The encryption like any asymmetrical method, relies on a
> sufficiently large encryption key based on all this data, that can be
> decrypted by the client (web browser) quickly since the private part of
> the key needed is known to the client.
Ok, I was aware that HTTPS entailed generating a session key the way
you are describing here.
> In theory, every encrypted data stream can be decrypted given enough
> time. That is why browsers quite quickly moved from 56-bit to 128-bit
> encryption after the more widespread introduction of using SSL. It is,
> even with "low-grade" encryption, still a time consuming process since
> the way to find the right key would be to brute-force the private key to
> decipher the data. For normal web use, 128-bits is quite sufficient but
> like I said given enough time that can also be broken and decrypted. Not
> easily though, and not simply by scripting something to run over a
> captured stream.
But this was the point of my question. You seem to be saying that,
having the encrypted sniffs, you can brute-force them eventually, and I
agree that this is (at least in theory) doable. What I am asking is:
does having the server public AND private key help you in any way to
decrypt the sniffed traffic? In other words, if I give you full sniffed
traffic for a couple of requests / responses, and ask you to decrypt
them, would it make any difference to you (faster, easier) if I also
hand you the server's public / private keys?
Best regards.
|
|
Posted by Anne & Lynn Wheeler on December 23, 2006, 4:23 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> But this was the point of my question. You seem to be saying that,
> having the encrypted sniffs, you can brute-force them eventually, and I
> agree that this is (at least in theory) doable. What I am asking is:
> does having the server public AND private key help you in any way to
> decrypt the sniffed traffic? In other words, if I give you full sniffed
> traffic for a couple of requests / responses, and ask you to decrypt
> them, would it make any difference to you (faster, easier) if I also
> hand you the server's public / private keys?
the (symmetric) session key is generated by the client, encrypted with
the server's public key and then transmitted to the server ... the
server then is able to obtain the session key value by decrypting it
with the server's private key (aka, given that you have access to the
server's private key ... then you can also access all session keys for
SSL sessions with that server). given that you have the server's
private key ... you can decrypt the transmitted session key ... w/o
having to resort to any brute force.
for little topic drift, rfc 4772 announced today ... "Security
Implications of Using the Data Encryption Standard (DES)" which includes
discussion on brute-force attacks ... ref
http://www.garlic.com/~lynn/aadsm26.htm#16 Security Implications of Using the
Data Encryption Standard (DES)
for various drifts ... lots of past posts mentioning SSL server digital
certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert
and lots of past posts mentioning (general) exploits, fraud,
vulnerabilities, and/or threats
http://www.garlic.com/~lynn/subintegrity.html#fraud
and lots of past posts discussing catch-22 for proposed improvements
in the SSL server digital certificate infrastructure
http://www.garlic.com/~lynn/subpubkey.html#catch22
basically implications of proposals for validation of SSL server
digital certificate applications which add digitally signatures and
verifying the application digital signature by doing a real-time
retrieval of public keys onfile with the domain name infrastructure
.... aka basically a certificateless infrastructure
http://www.garlic.com/~lynn/subpubkey.html#certless
which could then lead to everybody doing real-time retrieval of onfile
public keys ... eliminating the requirement for any digital
certificates. a certificateless public key infrastructure proposal
from old 1981 email:
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the
network
http://www.garlic.com/~lynn/2006w.html#15 more secure communication over the
network
http://www.garlic.com/~lynn/2006w.html#18 more secure communication over the
network
a recent thread with discussion of some other SSL server issues/vulnerabilities
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that
increases password security
http://www.garlic.com/~lynn/2006v.html#51 Patent buster for a method that
increases password security
http://www.garlic.com/~lynn/2006w.html#0 Patent buster for a method that
increases password security
http://www.garlic.com/~lynn/2006w.html#4 Patent buster for a method that
increases password security
http://www.garlic.com/~lynn/2006w.html#5 Patent buster for a method that
increases password security
|
|
Posted by MC on December 22, 2006, 6:31 pm
If you were Registered and logged in, you could reply and use other advanced thread options
authentication problem only. A different site can successfully identify
itself as the original owner. It does not mean the encryption is at risk
to be sniffed out as that is still done against the client's keys.
|
| Similar Threads | Posted | | Sign e-mail with server certificate | February 22, 2005, 4:17 pm |
| Re: Rebooting web server w/o having to type certificate passphrase? | June 11, 2007, 2:58 am |
| Re: Rebooting web server w/o having to type certificate passphrase? | June 15, 2007, 1:02 pm |
| Re: Rebooting web server w/o having to type certificate passphrase? | June 24, 2007, 5:28 am |
| Rebooting web server w/o having to type certificate passphrase? | June 11, 2007, 1:43 am |
| Howto setup a certificate authority and create a signed certificate using openssl on Debian sarge | March 16, 2005, 10:39 am |
| Question about Security Certificate Notices | November 21, 2008, 2:24 pm |
| Is there such thing as a multi-host security certificate? | July 25, 2007, 6:50 pm |
| Temporary FTP Server - Security | April 20, 2006, 2:05 pm |
| Server Co - Lo and 2 factor security | May 25, 2006, 3:21 am |
|
XML site map