Fixed false positive of mitm on CRiOS Chrome on iOS #1448
Conversation
| @@ -51,6 +51,9 @@ func (h *tlsHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) { | |||
| strings.Contains(ua, "Trident") { | |||
| checked = true | |||
| mitm = !info.looksLikeEdge() | |||
| } else if strings.Contains(ua, "CRiOS") { | |||
There was a problem hiding this comment.
The actual User-Agent string uses "CriOS" not "CRiOS"
| @@ -360,6 +363,58 @@ func (info rawHelloInfo) looksLikeFirefox() bool { | |||
| return assertPresenceAndOrdering(expectedCipherSuiteOrder, info.cipherSuites, false) | |||
| } | |||
|
|
|||
| // looksLikeChromeOniOS returns true if info looks like a handshake | |||
| // from a modern version of Chrome on iOS. | |||
| func (info rawHelloInfo) looksLikeChromeOniOS() bool { | |||
There was a problem hiding this comment.
What if we just called looksLikeChrome and then if false, checked for the one difference between the two which is the existence of that one cipher suite? Rather than duplicating almost the whole function.
|
hmmmm I was far too hasty earlier and I have investigated this a bit further and not sure how to proceed @mholt This is getting quite confusing and I'm wondering if its just me. To recap this issue only seem to happen on Chrome for iOS and only when fetching the favicon.ico file which is a special type of file retrieved. I have been working with the code and tried implementing as suggested above to use a single function etc. In part of my testing I found the Raw Client Hello for the first request to a new site requesting list.php and the second request requesting favicon.ico are completely different and offer completely different lists of ciphers etc.
and
The set of cipherSuites, curves and extensions are all different. Questions
I started writing tests and would need to write tests to pass both RAW Hello's? The list.php seems to pass as normal chrome but not the call to favicon.ico |
|
This is very spooky 👻 I would love to help, but I do not have an iPhone |
|
@elcore I presume I think doesn't happen with a new site on chrome on android? |
Chrome on Android doesn´t request |
|
@tobya This... is strange. Tell ya what, I have a test fixture set up that I've been using for people to help me test this, if you're online at the same time as me, just ping me on Twitter or Gophers Slack and I'll hop on if I'm available! Then we can get to the bottom of this I think. In the meantime, I hope if you don't mind if I close this PR. No doubt there's probably a bug somewhere in Caddy's code but we need to isolate it surely first. |
|
@mholt That's fine. Can you give me a vague time (your time of day) that might suit? Otherwise I'll ping you this evening Ireland time |
|
@tobya Most weekdays I'm good any time between 8-5, with a few exceptions for classes and things, but in general I work within that timeframe. |
|
Out of band, Toby was able to give me the information I needed to see this issue in a more controlled environment; turns out it has something to do with Chrome on iOS using WKWebView (out of requirement by Apple) for page loads but Chrome's own internals for favicon stuff. Thus, the page load looks exactly like Safari but the favicon looks like Chrome, but both have the same User-Agent. Hrm. I may have to wait until the researchers release their fingerprints before I can fix this properly. |
Issue discussed in #1430 with Chrome on iOS, which seems to use a Cipher that Chrome doesnt.
Created a new test for CRiOS (Chrome on iOS) that checks as for Chrome but with one less Cipher
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384Tested on Chrome on Windows and Chrome on iOS.
Chrome on iOS versions
Chrome verison:56.0.2924.79
iOS 10.0.2
@mholt The Client Hello is
Full Headers : https://gist.github.com/tobya/8ec9e4b6553264b6e2022b228a58f631#file-clienthello-log