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