2 ms·

I really believe this is an important study. To help expose MITM, I implemented HTTPS interception detection features into Caddy, based on the heuristics descri

by mholt 10y ago

I really believe this is an important study. To help expose MITM, I implemented HTTPS interception detection features into Caddy, based on the heuristics described in the paper: https://github.com/mholt/caddy/pull/1430 https://github.com/mholt/caddy/pull/1430 The web server is in a unique position to be able to detect interception where the browser can't, and then choose how to handle it (warn the client, log the event, whatever). If you want to test this feature, I welcome your bug reports! For example: {{if .IsMITM}} <b>We have reason to believe your connection is not private, even if your browser thinks it is.</b> {{end}} Or: redir { if {mitm} is likely /http-451-censorship.html } The researchers won't be releasing the fingerprints they collected until after NDSS '17 (March), but I'll look at taking those into account when they are available.

javajosh 10y ago
You're doing excellent work with Caddy, Matt. This solution of yours, which detects inconsistent headers on a single connection, is a good one. What will you do if and when MITM attackers do the extra work to duplicate headers?
- mholt 10y ago
  Thanks Josh, I appreciate it. Their method works by comparing the User-Agent HTTP header to the characteristics of the TLS handshake of the underlying connection. There are some exceptions, but TLS proxies generally don't touch the User-Agent HTTP header. Doing so runs the risk of breaking things at the application layer. TLS proxies probably don't care if they break things (hence the research) but a proxy that wants to hide (malware, censorship, etc.) would not want to risk breaking HTTP. This method, for the time being, should effectively force TLS proxies (who want to hide) to preserve the qualities of the original TLS connection. Then if the connection is weak, the browser can at least warn the user. I'm not certain this is a permanent solution, but given the eternal turnaround time of corporate products, I suspect it will be useful for years to come.

by mholt 10y ago

javajosh 10y ago

You're doing excellent work with Caddy, Matt. This solution of yours, which detects inconsistent headers on a single connection, is a good one. What will you do if and when MITM attackers do the extra work to duplicate headers?

mholt 10y ago
Thanks Josh, I appreciate it. Their method works by comparing the User-Agent HTTP header to the characteristics of the TLS handshake of the underlying connection. There are some exceptions, but TLS proxies generally don't touch the User-Agent HTTP header. Doing so runs the risk of breaking things at the application layer. TLS proxies probably don't care if they break things (hence the research) but a proxy that wants to hide (malware, censorship, etc.) would not want to risk breaking HTTP. This method, for the time being, should effectively force TLS proxies (who want to hide) to preserve the qualities of the original TLS connection. Then if the connection is weak, the browser can at least warn the user. I'm not certain this is a permanent solution, but given the eternal turnaround time of corporate products, I suspect it will be useful for years to come.