3 ms·

Wow, that's interesting. Does a network stack also have a characteristic that would factor in the fingerprinting of a client? TTL, maybe? And hardware (e.g. net

by 0xbkt 5y ago

Wow, that's interesting. Does a network stack also have a characteristic that would factor in the fingerprinting of a client? TTL, maybe? And hardware (e.g. network card) too.

0x0 5y ago
Yeah nmap can often be used to fingerprint OS versions for those reasons. Way back in the days around y2k many network stacks had poor or no randomization of some parameters that produced some neat looking plots: https://lcamtuf.coredump.cx/newtcp/ https://lcamtuf.coredump.cx/newtcp/
- ape4 5y ago
  Non an expert... are the ciphers in order of preference? So they can't really be randomized, I suppose.
  - IggleSniggle 5y ago
    The ciphers are in order of preference. The blog post hinted at this (I'm not sure why it didn't make it the primary suggestion), but you may be able to get away with simply duplicating a cipher. After reading the post, that's what I'm going to play with next time I run into this. I suspect duplicating will be fine in almost all environments, and by picking one way way down in the preference list to duplicate, I suspect you can increase the chances that there's nothing in the chain that will even have an opportunity to error based on the duplicated cipher preference. I tried this against the website quoted in the article and it worked without problem.
    - pimterry 5y ago
      I'm the author - I didn't pick duplicates as the main suggestion partly because it's not clear if all TLS servers will accept that, but also because it's trivial for TLS fingerprinters to detect and defeat that automatically if they chose too. They just need to always strip subsequent duplicates from the cipher list before hashing, and the whole technique becomes useless. I doubt that's happening today, but I suspect it will very quickly if duplicate ciphers become commonplace. Actually reordering ciphers meanwhile definitively changes the hash, so there's nothing they can do in the general case at least, and there's a reasonably large number of acceptable non-duplicate orderings available to choose from. Duplicating ciphers is a good technique that's definitely worth investigating too, but it has its limitations, and it's not a silver bullet.
      - PeterWhittaker 5y ago
        Re ECC and RSA: they rely on different classes of math problems, allowing for equivalent strengths with differing key sizes. ECC sizes are generally smaller, but that’s not the whole story, since some aspects of ECC allow for interesting attacks to which RSA, based on a much simpler problem, is not subject. See [1], e.g. In security, simplicity is often but not always by itself a win. Great article, btb, really appreciated the real world examples. 1: https://crypto.stackexchange.com/a/1194 https://crypto.stackexchange.com/a/1194
  - tinus_hn 5y ago
    This is a different application of random numbers. If you create a TCP connection, the server reply contains a sequence number. You have to know that number to establish the connection, so you can’t establish the connection unless you are able to receive the reply. If however you can predict the number, you can create a connection without being able to receive packets from the server. So if for instance an administrator has setup their machine to accept connections to an insecure service only from a specific IP address, you can now set up such a connection without actually controlling the IP address.
benmmurphy 5y ago
it is possible to fingerprint the TCP stack of the client from their first SYN packet (and possibly other packets?) the only online demos of this i know of are: http://witch.valdikss.org.ru/ http://witch.valdikss.org.ru/ and https://bot.incolumitas.com https://bot.incolumitas.com i believe the WITCH site is based on p0f (https://lcamtuf.coredump.cx/p0f3/ https://lcamtuf.coredump.cx/p0f3/) i know some people have custom patches to the linux kernel to make it look like a different operating system in order to work around bot detection.
jeroenhd 5y ago
There are several factors that can be fingerprinted passively. Timings, optional flags across the protocol stack, you name it. Detecting specific versions of an OS can be more difficult, especially passively, but you should be able to do it if you have enough data. A particularly useful anti-bot feature is to fingerprint TLS connections by things like cipher order and available signatures (if you're willing to switch back to TLS 1.2). This way, you can easily detect the difference between browsers and bots, even if all the request headers match . If you're fine with blocking people behind middleboxes or proxies then it can be a simple yet useful fingerprinting technique.

by 0xbkt 5y ago

Wow, that's interesting. Does a network stack also have a characteristic that would factor in the fingerprinting of a client? TTL, maybe? And hardware (e.g. network card) too.

0x0 5y ago

Yeah nmap can often be used to fingerprint OS versions for those reasons. Way back in the days around y2k many network stacks had poor or no randomization of some parameters that produced some neat looking plots: https://lcamtuf.coredump.cx/newtcp/ https://lcamtuf.coredump.cx/newtcp/

ape4 5y ago
Non an expert... are the ciphers in order of preference? So they can't really be randomized, I suppose.
- IggleSniggle 5y ago
  The ciphers are in order of preference. The blog post hinted at this (I'm not sure why it didn't make it the primary suggestion), but you may be able to get away with simply duplicating a cipher. After reading the post, that's what I'm going to play with next time I run into this. I suspect duplicating will be fine in almost all environments, and by picking one way way down in the preference list to duplicate, I suspect you can increase the chances that there's nothing in the chain that will even have an opportunity to error based on the duplicated cipher preference. I tried this against the website quoted in the article and it worked without problem.
  - pimterry 5y ago
    I'm the author - I didn't pick duplicates as the main suggestion partly because it's not clear if all TLS servers will accept that, but also because it's trivial for TLS fingerprinters to detect and defeat that automatically if they chose too. They just need to always strip subsequent duplicates from the cipher list before hashing, and the whole technique becomes useless. I doubt that's happening today, but I suspect it will very quickly if duplicate ciphers become commonplace. Actually reordering ciphers meanwhile definitively changes the hash, so there's nothing they can do in the general case at least, and there's a reasonably large number of acceptable non-duplicate orderings available to choose from. Duplicating ciphers is a good technique that's definitely worth investigating too, but it has its limitations, and it's not a silver bullet.
    - PeterWhittaker 5y ago
      Re ECC and RSA: they rely on different classes of math problems, allowing for equivalent strengths with differing key sizes. ECC sizes are generally smaller, but that’s not the whole story, since some aspects of ECC allow for interesting attacks to which RSA, based on a much simpler problem, is not subject. See [1], e.g. In security, simplicity is often but not always by itself a win. Great article, btb, really appreciated the real world examples. 1: https://crypto.stackexchange.com/a/1194 https://crypto.stackexchange.com/a/1194
- tinus_hn 5y ago
  This is a different application of random numbers. If you create a TCP connection, the server reply contains a sequence number. You have to know that number to establish the connection, so you can’t establish the connection unless you are able to receive the reply. If however you can predict the number, you can create a connection without being able to receive packets from the server. So if for instance an administrator has setup their machine to accept connections to an insecure service only from a specific IP address, you can now set up such a connection without actually controlling the IP address.

benmmurphy 5y ago

it is possible to fingerprint the TCP stack of the client from their first SYN packet (and possibly other packets?) the only online demos of this i know of are: http://witch.valdikss.org.ru/ http://witch.valdikss.org.ru/ and https://bot.incolumitas.com https://bot.incolumitas.com i believe the WITCH site is based on p0f (https://lcamtuf.coredump.cx/p0f3/ https://lcamtuf.coredump.cx/p0f3/) i know some people have custom patches to the linux kernel to make it look like a different operating system in order to work around bot detection.

jeroenhd 5y ago

There are several factors that can be fingerprinted passively. Timings, optional flags across the protocol stack, you name it. Detecting specific versions of an OS can be more difficult, especially passively, but you should be able to do it if you have enough data. A particularly useful anti-bot feature is to fingerprint TLS connections by things like cipher order and available signatures (if you're willing to switch back to TLS 1.2). This way, you can easily detect the difference between browsers and bots, even if all the request headers match . If you're fine with blocking people behind middleboxes or proxies then it can be a simple yet useful fingerprinting technique.