ssllabs / sslhaf Goto Github PK

The BEAST detection code assumes all client writes will use the 1/n-1 split. However, the first write is not vulnerable to the attack, which is why some clients split from the 2nd write onwards.

The solution is to watch for the 2nd and 3rd write, and detect mitigations based on that. Further, because most HTTP requests consist of a single write, BEAST mitigation will work only when enough data is sent by clients. In practice, that means only longer POST requests.

On a fairly standard Ubuntu saucy install, I can build sslhaf, but not mod_sslhaf:

$ sudo apxs2 -ci -I/usr/local/include/sslhaf/ -L/usr/local/lib/ -lsslhaf mod_sslhaf.c

/usr/share/apr-1.0/build/libtool --silent --mode=compile --tag=disable-static x86_64-linux-gnu-gcc -std=gnu99 -prefer-pic -pipe -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wformat-security -D_FORTIFY_SOURCE=2 -fno-strict-aliasing  -D_FORTIFY_SOURCE=2   -DLINUX -D_REENTRANT -D_GNU_SOURCE  -pthread  -I/usr/include/apache2  -I/usr/include/apr-1.0   -I/usr/include/apr-1.0 -I/usr/include -I/usr/local/include/sslhaf/  -c -o mod_sslhaf.lo mod_sslhaf.c && touch mod_sslhaf.slo
mod_sslhaf.c: In function 'mod_sslhaf_log':
mod_sslhaf.c:230:31: error: 'conn_rec' has no member named 'remote_ip'
         "mod_sslhaf [%s]: ", c->remote_ip);
                               ^

There's more, but the errors are all around remote_ip.

Objects embedded in the client handshake include: cipher suites, compression methods
and TLS extensions

In addition to the string of ids currently being parsed out, extract more comprehensive
information:

• cipher suites - embed full cipher description including nice name and algorithm key length. This information will be sourced from the suites.csv document included in the source tree. It will be processed into a source file: sslhaf_suites.c which contain lookup routines that return a suite description given an id number. The main lookup function will be exported in sslhaf.h as a useful utility function.
• compression methods - store a printable string of comma separated compression method ids as well as an array of ids
• extensions - store extension information as the existing list of printable ids, but in addition, provide a traversable list of objects with more detailed extension information. The object will have a standard header containing the extension name, the id and an enumeration key, and a union of subobjects. The real subobject stored in the union will be demarcated by the extension key in the header, which will either indicate a supported extension object type, or indicate a generic 'unsupported' type.

TLS allows lower-level protocol records to be fragmented, but this case is not handled in the code. This happens only rarely, and then usually as a result of server misconfiguration. (For example, one recent case I observed was when the server was configured to send too many certificates.)