HTTPS Client Identification Using SSL/TLS Fingerprinting(muni.cz)
muni.cz
HTTPS Client Identification Using SSL/TLS Fingerprinting
https://www.muni.cz/research/publications/1299983?lang=en
5 comments
This is a huge issue. We really need leaders to start being aggressive with bringing down the variation. It's damaging the benefit of using TLS at all, and I'd argue browser vendors would be making their users safer by having browsers force HTTP (or outright reject) on websites that aren't maintained enough to do TLS1.2 than allowing HTTPS and ultimately hurting the whole ecosystem.
I don't see a mention of timing in this paper, either. I suspect that it is another viable identifier. After accounting for latency, the speed of the response can give you an idea of what hardware they're using.
I don't see a mention of timing in this paper, either. I suspect that it is another viable identifier. After accounting for latency, the speed of the response can give you an idea of what hardware they're using.
I don't really get the point of getting the user agent with this technique. How useful is it? It's not really fingerprinting. You can't identify a computer uniquely. Pretty much all iphones have the same user agent.
Another input for a Bayesian bot detection algorithm. If it looks like Forefox but doesn't use cipher suites for, any released version of Firefox then it might not be Firefox.
It's actually a less intrusive test than say searching the network for SIP end points via WebRTC like used today.
It's actually a less intrusive test than say searching the network for SIP end points via WebRTC like used today.
OpenSSL has a hack similar to this to workaround a bug in Apple's ECDSA implementation where it was unusable in older versions of OS X and iOS.
Dropping "Network-based" from the name makes it a bit misleading/confusing...
[slides] http://is.muni.cz/repo/1299983/https_client_identification-s...