Open drwetter opened 4 years ago
If i remember correctly IIS also has a very specific fragmentation style. I am not sure how it exactly looks like from the back of my mind, but I think they send each message in an individual record + in an individual tcp packet. something like that.
TCP fragmentation is not something we can catch
I believe those ciphers should not be available in Windows:
See also:
taken from here: https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel.
In fact all those ciphers I mentioned are not even in Windows 2010. If we would encounter those it then would look more like a middle box. Probably a middle box (my knowledge is weak here) doesn't support those either, but if we can squash a certain percentage of fp, it is something.
Curves maybe also a thing to look at but they are the common ones and I only found https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786433(v=ws.11)#ecc-cipher-suites
My educated guess for the exclusion list for the TLS extensions would be
I was looking at the IANA list https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml, there the date of RFCs (late 2014 and younger), and testssl'ing modern systems.
Wrt Heartbeat: this was earlier than 2014 but I can't remember seeing this extension on Windows. There are always very small number of extensions IIRC. So can be achieved by this is preventing fp because of middle boxes.
Also there's a difference between date of the RFC and implementation. I assume here however MS didn't care much about RFCs so I do not expect MS to implement an internet standard ahead of time.
@dcooper16 : what's your take on this?
. I assume here however MS didn't care much about RFCs so I do not expect MS to implement an internet standard ahead of time.
from https://tools.ietf.org/html/rfc7627
Internet Engineering Task Force (IETF) K. Bhargavan, Ed.
Request for Comments: 7627 A. Delignat-Lavaud
Updates: 5246 A. Pironti
Category: Standards Track Inria Paris-Rocquencourt
ISSN: 2070-1721 A. Langley
Google Inc.
M. Ray
Microsoft Corp.
September 2015
This 2016 rollup may also be an indicator that the system's SChannel is earlier:
https://support.microsoft.com/en-us/help/3161639
Cipher suite | FIPS mode enabled | Protocols | Exchange | Encryption | Hash |
---|---|---|---|---|---|
TLS_DHE_RSA_WITH_AES_128_CBC_SHA | Yes | TLS 1.2, TLS 1.1, TLS 1.0 | DHE | AES | SHA1 |
TLS_DHE_RSA_WITH_AES_256_CBC_SHA | Yes | TLS 1.2, TLS 1.1, TLS 1.0 | DHE | AES | SHA1 |
No idea whether this rollup can be installed independent of KB 2992611 ??
I have here an example of a "middle box" which seems in fact an Apache proxy -- telling by the HTTP server banner change from "/" to it's final destination. Here, the server's ciphers prevented a false positive when accessing the final path.
The Apache has the following TLS extensions which are
"server name/#0" "renegotiation info/#65281" "EC point formats/#11" "session ticket/#35" "heartbeat/#15"
Question is here which extension can be excluded under Windows Server 2012 / 2012R2.
Also (this is a pending todo): If I read the references above correctly Windows Server <=2012R2 supports only P384, P256 and optional P521 (secp384r1, secp256r1 =prime256v1, secp521r1). The Apache middle box had also prime256v1 secp256k1
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
Hi @banderson84, I am doing fingerprinting on an old server side bug (MS14-066), thus I've seen your project @ https://github.com/cisco/joy which could be helpful.
Can you tell for sure which TLS extensions should NOT show up in Windows Server 2012 / Windows 2012 R2 ? Currently encrypt-then-mac
and max fragment length
are those only I use for fingerprinting based on https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Extensions . I am interested in server side extensions only and ones which WONT EVER show up when testing the server directly.
I am not sure about heartbeat
and supported_groups
. How about ec_point_formats
?
I don't have good ground truth on servers, so I can't check which TLS extensions don't show up. I do think looking at the data within the supported_groups
or ec_point_formats
extensions would be helpful.
fwiw, we have a new open source project specifically targeted at fingerprinting (including TLS server fingerprinting): https://github.com/cisco/mercury. I see ~1 billion TLS server fingerprints a day, but I don't know what operating systems or TLS libraries generated them.
I don't think server and clients differ much, see resources above from Microsoft regarding SChannel. According to that Windows 8 is identical to Server 2012, and 8.1 to Server 2012 R2. This is at least where I got the differences in cipher suites and the curves from.
As said, what's left are a few extensions.
Mercury seems interesting, too. Thanks
Currently we're looking at
we carefully label this a a finding.
In a discussion at twitter @ic0ns came up with the (great) idea also to look at the extensions. So what we could do additionally is looking at extensions which came later (>2014) or any other one which is unlikely to be used e.g. in a windows context or with server 2012/R2 or 2008/R2.
cc @dcooper16
In the case with Server 2012 I have here there were only
detected.