tags:

views:

32

answers:

1

Hello,

Presently I am working on a firewall project. First thing I have to do if any user wants to access illegal site I will not let him do so. So I am tracking TCP packets. So far for HTTP requests I don't have any problem. But for HTTPS I do have some problems. I am unable to recognize a HTTPS packet. Can any one help me on that please?

Thanks.

+2  A: 

There's no way to recognize an HTTPS request (that is, there's no way to distinguish an HTTPS request from any other SSL-wrapped request).

The best you could do would be to learn the format of the different SSL handshakes (Google search) and recognize them and compare the destination to your blacklist.

Adam Robinson
Thanks. Very valuable advice.
Harun
But I wonder how WireShark do that ?
Harun
The destination will be at the TCP/IP level, you don't need to process the SSL/TLS handshake for this. (For HTTPS: port 443 by default.)
Bruno
@Harun: Most monitoring programs like WireShark or Fiddler execute what are essentially man-in-the-middle attacks on the communication. They use a self-signed certificate that says they're the remote host, then negotiate an SSL connection with the client using that certificate then another with the server as a client. It then decrypts the communication between the client and server (since it's the one with the actual connection), then reencrypts it using the appropriate certificate for the destination.
Adam Robinson
@Bruno: Yes, that's obviously true, but I'm assuming that exercise here is to do some sort of DPI as part of the firewall (I'm assuming this is a college project).
Adam Robinson
The only relevant thing you'll see during the handshake is the certificate is the server certificate (and the client certificate if there is one and if the client cert negotiation is initial/not renegotiated), the rest will be encrypted. What could also be relevant is to look at connections to HTTP proxy servers, as you'd be able to see to which machine the connection is made by inspecting the `CONNECT` command.
Bruno
@Bruno: Again, I'm not trying to say that inspecting the SSL handshake will be *valuable*, but if the point of the exercise is to be able to identify what it *is*, then simply looking for a connection on 443 is likely not going to be sufficient.
Adam Robinson
Indeed, I agree :-)
Bruno