[Oisf-devel] [PATCH] Add TLS handshake decoder 0/3

[Victor Julien]

Hi Pierre, thanks for doing this awesome work!

On 10/25/2011 02:10 PM, Pierre Chifflier wrote:
> Here is a patchset to add some support for extracting information from
> the TLS handshake. The patches are based on the current master branch.
> 
> The goal is to be able to read the certificates and extract a few
> keywords. This gives a few opportunities:
> - using some kind of hash function, it's possible to test if a known
>   certificate for a site changes,

I like this idea very much.

> - we can define some keywords on TLS records, for ex. extract the chosen
>   cipher for the session. I'm intending to use this to be sure the server
>   or the client are not trying to do some kine of downgrade attack with a
>   weak cipher
> - we can have some keywords on TLS certificates, to match some subjects
>   etc.

Great.

> It's /possible/ to use it to do some advanced things like decode the
> session (knowing the private keys), but it's not what I'm discussing here.
> 
> Details
> - -------
> 
> The first thing to do is to follow the TLS handshake to get the
> SSLV3_HS_CERTIFICATE message (from the server). This message contains a
> list of certificates, starting from the server certificate and
> (optionaly) the chain up to the authority.
> The only trick here is that TLS records can be fragmented across TCP
> packets, and also packed (several records in one TCP packet, which can
> be fragmented etc.). We get the server certificates and parse the list.
> 
> Now, we can focus on the certificate itself. The binary encoding
> of a certificate is DER, which is a kind of TLV on an ASN.1 structure.
> For more details, see the X690 documents from the ITU, especially
> X.690-0207 for ASN.1/DER, and RFC 3280 for X509v3.
> Reading the ASN.1 structure is not difficult by itself, we just build a
> tree of items, which are nested sequences/sets/structured items and
> primary types.
> What can drive you nuts is parsing/understanding the values: the are
> optional (implicit, explicit) items, context-specific items where the
> type is determined by the knowledge of the structure, unknown ones etc.
> The parser builds the tree structure with known items by reading them
> recursively. Unknown types are handled (because the size is known) and
> treated as blobs.
> Then, with the structure, we can extract the fields from the
> certificate. Some fields (like the CN) can be read directly (given the
> position in the tree), while classical values like the Subject (or
> Issuer) of the certificates are not direct values, but built by
> iterating on the list of the corresponding node, and adding separators.
> 
> Finally, this is used to create a keyword in the parser (tls.subject),
> searching the subject of the *first* certificate (the server) for a
> substring match.
> 
> Example rule:
> alert tls $HOME_NET any -> $EXTERNAL_NET 443
> (tls.subject:www.google.com; msg:"test sig TLS Subject"; sid:8888890;
> rev:1;)
> 
> The last patch also decode the SERVER_HELLO message, which contains some
> information on the protocol (ciphersuite) and compression chosen by the
> server during the negotiation. Some keywords will also be added to match
> that, they are not yet added due to the complexity to easily handle the
> multiple protocol families, key lengths, and cipher suite names.
> 
> Note that app-layer-ssl.c (which is badly named, it really should be
> app-layer-tls.c) should be heavily changed to handle properly TLS
> records fragmentation, size, etc. It is not yet done to keep patches as
> simple as possible, and readable.

Okay, cool. I have no objection to renaming it to *tls* and I agree we
need improvements in the parsing as well.

I'll comment the individual patches separately.

Cheers,
Victor

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------