3 ms·

"This is actually a very common scenario anytime a laptop connects to a hotspot before the user signs in where the laptop will attempt to connect to Gmail if th

by tarkin2 19y ago

"This is actually a very common scenario anytime a laptop connects to a hotspot before the user signs in where the laptop will attempt to connect to Gmail if the application is opened but it won't be able to connect to anything." I'm sure this sentence just flowed in the author's head, but what? It's a pity because this is the most crucial sentence in the article.

dkokelley 19y ago
I think what it means is that if you have an application that logs into gmail (either as a home page when you open your browser, google talk or other compatible client, or an email client such as outlook) automatically (after you've connected to the network but before you're connected to the internet) the application will try again, disabling ssl to see if that works. After you've finally connected to the internet, your application will log in to Gmail and open a session in Gmail without ssl. Then someone who is monitoring the unencrypted data will be able to sidejack your session. I'm pretty sure this is how it works, but correct me if I'm wrong.
- tarkin2 19y ago
  That sounds about right, thanks; however it depends on the extant client-side javascript reverting to http while you're not connected to the internet, as pmjordan said.
pmjordan 19y ago
Yeah, I wish he'd been clearer about that. I'll take a stab at deciphering it though: You've just connected your laptop's wifi to a hotspot (i.e. associated with the access point) but haven't yet logged in/paid. Connection attempts will now either re-route to the hotspot operator's login page or just fail, depending on how the hotspot is set up. Now, suppose, for whatever reason, gmail is still open in your browser from a previous session or whatever. It will keep trying to connect to the server via https, which fails as there's no route to it, and (according to the article) fall back to http. (which will also fail, but can be intercepted) I don't see how this will work unless you've still got the gmail client-side scripts executing from your browser's cache. Simply navigating to https://gmail.com/ https://gmail.com/ will fail, and the retry/redirect won't ever happen. Disclaimer: I don't know the inner workings of gmail; I've never looked into how gmail works at all. Edit: spelling

by tarkin2 19y ago

dkokelley 19y ago

I think what it means is that if you have an application that logs into gmail (either as a home page when you open your browser, google talk or other compatible client, or an email client such as outlook) automatically (after you've connected to the network but before you're connected to the internet) the application will try again, disabling ssl to see if that works. After you've finally connected to the internet, your application will log in to Gmail and open a session in Gmail without ssl. Then someone who is monitoring the unencrypted data will be able to sidejack your session. I'm pretty sure this is how it works, but correct me if I'm wrong.

tarkin2 19y ago
That sounds about right, thanks; however it depends on the extant client-side javascript reverting to http while you're not connected to the internet, as pmjordan said.

pmjordan 19y ago

Yeah, I wish he'd been clearer about that. I'll take a stab at deciphering it though: You've just connected your laptop's wifi to a hotspot (i.e. associated with the access point) but haven't yet logged in/paid. Connection attempts will now either re-route to the hotspot operator's login page or just fail, depending on how the hotspot is set up. Now, suppose, for whatever reason, gmail is still open in your browser from a previous session or whatever. It will keep trying to connect to the server via https, which fails as there's no route to it, and (according to the article) fall back to http. (which will also fail, but can be intercepted) I don't see how this will work unless you've still got the gmail client-side scripts executing from your browser's cache. Simply navigating to https://gmail.com/ https://gmail.com/ will fail, and the retry/redirect won't ever happen. Disclaimer: I don't know the inner workings of gmail; I've never looked into how gmail works at all. Edit: spelling