"Varga, Jack" <[EMAIL PROTECTED]> writes:
> Along the lines of a Stephens TCP packet header illustration,
> is there something similar to describe an https (or http for that
> matter) packet header?
The first thing to realize is that HTTPS means "HTTP over SSL".
Ordinarily, HTTP traffic is carried as the payload of TCP packets.
In HTTPS, the payload of TCP packets is SSL records which themselves
contain the HTTP traffic-encrypted. Unless you have the private
key of the server, there's no way to recover any of the HTTP
data (that's the point of the exercise.) Even if you do have the
private key of the server, this operation would be rather expensive
computationally--roughly as expensive as running an HTTP server.
> My understanding is that unlike IP and TCP headers that
> are fixed length, HTTP (and HTTPS) are ":" delimited. Does this
> imply that the only way to retrieve data from them is with an
> API call?
It's true that HTTP headers are : delimited. Stevens's
TCP IP Illustrated volume 3 contains a description of
HTTP. However, if you're running HTTPS you'll need to decrypt
the traffic first.
> In particular, what I "think" I would like to do is grab the SSL
> session_id from the serverHello and build a table with this
> information, (i.e. source_ip:port, destination_ip:port, session_id,
> timestamp).
You CAN recover the SSL session id without decrypting anything.
You will however have to parse the SSL handshake message. The SSL
handshake message format is described in RFC 2246.
Any SSL implementation will contain code that knows how to decode
the ServerHello. You could easily extract that code from OpenSSL.
If you want it in a sniffer, you can get it from ssldump.
> I'm working with a gateway service that uses DNS to return a
> destination ip to the client of the gateway front end. The
> front end gate takes the data portion of the incoming
> packet prepends a new ip header and delivers to the gateway
> back end which is integrated with the web server. Currently,
> for non SSL traffic the true destination is extracted from
> http header where the front end keeps a host file like table
> for routing to the correct destination ip.
I don't see how this is going to work with SSL. There's no
indication in the SSL handshake of which host the client is
trying to connect to (except the IP address, which you say you're
spoofing.).
I'd say your best bet is to put the SSL decryption stage on the
gateway and then proxy the HTTP to the server.
I.e.
Client <-------HTTPS-------> Gateway <-------HTTP-------> Server
Note that you'll have to use the private key/certificate for
all the traffic, however.
> Is there a legitimate way to extract the destination host
> from within an SSL clientHello? Relatedly, I would then need
> the session_id from the responding serverHello at which point
> I could build a hash table within the gateway service to manage
> the rest of the session.
No. The information isn't in there.
-Ekr
[Eric Rescorla [EMAIL PROTECTED]]
Author of "SSL and TLS: Designing and Building Secure Systems"
http://www.rtfm.com/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
