Point-and-Click Gmail Hacking Shown at Black Hat

not5150 writes "Using Gmail or most other webmail programs over an unsecured access point just got a bit more dangerous. At Black Hat Robert Graham, CEO of errata security, showed how to capture and clone session cookies very quickly over connections without encryption. He even hijacked a shocked attendee's Gmail account in the middle of his presentation. 'While Ou was typing, Graham was running Ferret and sniffing all the cookies that were being sent from Ou's laptop and Google. Graham then clicked on Ou's IP address and Gmail page, complete with Ou's recently sent message on the screen. We photographed both Graham's and Ou's laptop at that time and posted it to the picture gallery. You'll see that the contents are exactly the same.'"

Slow News day?

[OverlordQ]

Somebody intercepted plaintext on an open network . . . . did I miss something?

Re:

[Cancel-Or-Allow]

The funny thing is, gmail offers the ability to sign-in securely, but not an option to keep it SSL throughout the entire session. It works when you manually change the http to https in the url after signed in, but there is still brief moment of unsecured traffic during this process.

Re:Slow News day?

[zippthorne]

That's odd. I go to https://mail.google.com/ and at no time during the login process do I ever see the address bar go from yellow to white. Are you sure it still works the way you say? Or is it sending something unencrypted so fast that I'm just not noticing (which would be kind of worrying).

Re:Slow News day?

[tizan]

I believe if you use https://gmail.google.com/ [google.com] (note gmail instead of mail) your whole mail session is always encripted and not the login page only.

Re:Slow News day?

[SanityInAnarchy]

Because this means more computing for google servers.

This is Google we're talking about. They can take it.

I mean, seriously, even an old 200 mhz Linux box set up as a server can do crypto at wire speed (100 mbit ethernet). I'm sure it takes them more cycles to spellcheck it for you.

And also because your mail is sent as plain text to the recipient's mail server (and it came as plain text on google server). So it would be useless to crypt only the first (or last) part of the way.

"Not entirely secure" is not the same thing as "useless".

Consider: The majority of most websites are mostly served as plain HTML over HTTP. Is it still "useless" for me to admin mine using SSH instead of unsecured FTP? I think not.

The point I am making here is, if your communications with Gmail are unencrypted, it makes it possible for someone to not only intercept the content of the message, but alter it -- they could, in fact, hijack your whole session, gain access to your archived mail, and send mail pretending to be you. All of this is theoretically possible with that SMTP connection between Gmail and another mailserver, but it's also insanely difficult to get anywhere close to what you can get by hijacking the session.

And there's even a point to encrypting it, as opposed to just signing it. Well, two points, actually:

1. Browsers include SSL natively, but there's no spec for just signing something and sending it plaintext. Therefore, it would have to be done in JavaScript, which is MUCH slower.
2. SMTP is only used for connections between Gmail and other servers. Mail sent between you and another Gmail address is entirely secure, once it gets to the server. Why let people hijack your session and make it insecure?

I mean, I tend to agree with you somewhat -- I only really do email from the one machine that has my GPG key, and I wouldn't use Gmail for more than backup. I don't see much point to webmail, because I never login to anything from a computer that isn't my own, because I don't like exposing myself to keyloggers.

But even if it can't be very secure, why make it even less secure than it can be?

Re:

[Sancho]

You can actually sniff the traffic to see that your browser is making requests to Gmail over port 80. It's that magical Web 2.0 crap--you can't really tell what your browser is doing by the visual cues that have worked so well in the past.

Re:Slow News day?

[gpuk]

That is the correct behaviour.

Essentially, if you enter via http://mail.google.com/ [google.com] Google remembers this and encrypts only the login process and then reverts back to plain text. If you enter via https://mail.google.com/ [google.com] your session remains encrypted throughout.

Re:

[zippthorne]

It IS a silly default, though. All you have to do is forget to type it manually just once and bam, plaintext. Anyone can read the subjects of emails sent to you at the very least.

I mean, yeah, some people might not care about security, but that's no reason to make the default inherently insecure. At the very least, they could have the first view not actually show the contents of the inbox, so when you log in insecurely by mistake, you can switch to secure without actually compromising anything.

But it IS

Re:

[RubberDogBone]

Well, I dunno about you but I use one main PC at home, one Mac laptop, and one PC at work, and I have setup all three with a toolbar bookmark that goes to the secure Gmail session. https://mail.google.com/ [google.com]

That makes it easy to connect the right way. It doesn't take long to type by hand either.

Re:Slow News day?

[Kartoffel]

That's easy enough to fix with a Firefox plugin: http://www.customizegoogle.com/ [customizegoogle.com]

Another Extension

[lupine]

I use the Gmail Notifier [mozilla.org] firefox extension which checks for messages and forces gmail to use secure connections.

Re:

[Brian Gordon]

Even if they did somehow get your session cookie, you're logged in via a secure connection (:443) and I'm sure it would be noticed by google if they tried to use your session cookie to log in without your SSL credentials- which of course there's no way to get.

Re:

[Daytona955i]

If you just type in mail.google.com and rely on your browser to prepend the http:/// [http] for you, it will direct you to the secure page for login and then back to the non-secure page for email. If however, you initially type in https://mail.google.com/ [google.com], login, you will stay on https.

Bottom line

[Kadin2048]

I think the upshot of this isn't really "look at us, we can sniff plaintext Wifi connections," but "look at one of the biggest players in web mail use plaintext connections even though they ought to know it's a hideously bad idea."

It's more of an indictment of Google than anything, because they default to unencrypted HTTP rather than HTTPS, and most users won't know that they can go to https://mail.google.com/mail/ [google.com] to force smarter behavior.

Re:Bottom line

[It'sYerMam]

And furthermore, if you use google via a customised google page (http://www.google.com/ig) then even if you redirect that to https://.../ [...] then the link to GMail is still regular http.

Re:

[HitekHobo]

I'd be a lot more impressed if they had altered Doug Song's toolsuite from 7 years ago to use wifi at layer 2.

Dsniff / Monkey in the middle attacks [monkey.org]

Re:Slow News day?

[Anonymous Coward]

if the traffic is sniffed as the browser is sending the SSL requests, one could sniff the SSL key and just use that to get in.

You have no idea how SSL works.

Re:Slow News day?

[tom17]

Seemingly neither do the people in the comments section at the bottom of TFA :-(

Worrying.

Re:

[kdemetter]

it is possible however . it basically works be faking the certificate .
Cain does it that way . The user does get a notification that the certificate is untrusted , but most people will just allow it anyway ( otherwise they can't use the webpage ) .

Re:Slow News day?

[The Velour Fog]

Also, logging in via SSL doesn't always work either - if the traffic is sniffed as the browser is sending the SSL requests, one could sniff the SSL key and just use that to get in.

SSL uses Diffie-Hellman key exchange [wikipedia.org] so no unencrypted key is ever sent

Re:

[Cajal]

that depends on what SSL ciphersuite your browser negotiated. Some SSL ciphersuite support DHE keying. For others, the client generates a random key, encrypts it with the server's public key, and sends it to the server.

Ciphers and key exchange mechanisms are discrete.

[Medievalist]

that depends on what SSL ciphersuite your browser negotiated. Some SSL ciphersuite support DHE keying. For others, the client generates a random key, encrypts it with the server's public key, and sends it to the server.

Huh? I know TLS theoretically supports other key transfer mechanisms than diffie-hellman, but the last time I checked there wasn't anything else actually implemented, it's just a future compatibility mechanism. I haven't studied SSL since TLS came out, but I don't remember there being any way to avoid diffie-hellman in SSL at all.

I think you'll need to provide some corroborating evidence, my friend. Care to point to a section in the spec where it says you can skip secure key exchange, or post some code,

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[gkhan1]

As some other posters said, this is absolutely not true and it hasn't been true since asymmetric cryptography and secure key exchanges where discovered.

However, if the hacker was able to set himself up as a proxy between the computer and the network (by using ARP spoofing, for instance), he could substitute his own certificate for Google's, decrypt the traffic, read it, and then forward it to Gmail (that is, a man-in-the-middle attack). This takes way more work, and there will be a popup that says "This c

Re:

[Burz]

This takes way more work, and there will be a popup that says "This certificate has not been signed by a trusted authority, someone might be trying to sniff you out". No one with a tiny bit of computer security knowledge would fall for this, but a clueless user who clicks "Allow" on everything probably would be.

And I try to educate everyone I know about handling certificate warnings. They are all worried about Internet insecurity, and I tell them their connection (assuming they have a clean systems) WILL be

Could be fixed easily by Google. Shame.

[OpenGLFan]

This is shameful. It's 2007, Google. SSL has been a (reasonable) standard since 1996. USE IT.

Re:

[ohearn]

Gmail will use SSL over any browser, it just doesn't by default (which is a shame, but easily fixed for those of us that care)

Re:Could be fixed easily by Google. Shame.

[SatanicPuppy]

They offer it. All you have to do is go to https://mail.google.com/ [google.com] rather than http://mail.google.com./ [mail.google.com]

I fail to see how the average person, as usual, being lax about their security is in any way Google's fault. This was something I found immediately, just because I won't check my email without a secure connection.

Re:Could be fixed easily by Google. Shame.

[Bob 535604]

I fail to see how the average person, as usual, being lax about their security is in any way Google's fault. This was something I found immediately, just because I won't check my email without a secure connection.

A lot of people wouldn't know about this or even look for it and you know it. Google could make https the default or even mandatory, and it would completely kill this entire issue.

Re:

[badfish99]

It's obviously much more expensive in terms of load on the server. And Google presumably take the attitude that anyone who is willing to hand all their email over for Google to look at must not care about security anyway.

Re:

[cheater512]

All of the above. It needs significantly more cpu, bandwidth and isnt good for compatibility.

Re:

[awing0]

What do you mean, it isn't good for compatibility? SSL dates back to the early 90's and was present in the two major browsers (Netscape and IE) by 95 or so. Any platform not supporting SSL today does not have any excuses.

Re:Could be fixed easily by Google. Shame.

[TheRaven64]

A huge part of security is having sane defaults. If you support 'secure' and 'insecure' you should default to 'secure,' and let users who know what they are doing, and need 'insecure' behaviour opt into it. You shouldn't default to 'insecure' and make it the users' responsibility to select 'secure.'

Yes, but...

[mattgreen]

You forgot this is Google who has erred here, and they have been shown to be Good, so you get people defending their poor security practices simply because they like Google. Are you new here? ;)

Re:

[SatanicPuppy]

What error? Did they ever claim it was secure to send email over an unsecured connection? The service is provided: "...on an AS IS and AS AVAILABLE basis. Google disclaims all responsibility and liability for the availability, timeliness, security or reliability of the Service. Google also reserves the right to modify, suspend or discontinue the Service with or without notice at any time and without any liability to you." Gmail Terms of Use [google.com]

If you thought anything else, you were out of your fricking mind...I

Re:

[mattgreen]

So now it isn't an error?

Unbelievable. Secure by default is not a nice feature, it is the ONLY option when properly engineering something. Free or otherwise. If you think otherwise, then you're doing a grave disservice to your users. Anyway, I'm looking forward to quoting this thread in future security discussions. Evidently, security isn't as important these days, or, it isn't if you're Google.

Oh come on.

[SatanicPuppy]

If they had enabled SSL be default, they'd be the only free web mail provider to have done so. That's the way it's done. If you don't like it, might try using a service you have to pay for.

Re:

[InvisblePinkUnicorn]

They default to insecure because if everyone was using their secure server, it would implode. People shouldn't need their hands held.

Re:

[It'sYerMam]

You've both implied that people should use the secure server on their own, and that doing so would cause Google's server to break. If Google's secure server doesn't have the capacity to handle a significant proportion of the user base, then that is in effect a wish for people not to use the service securely. Regardless of people not needing their hands held, Google apparently doesn't want to implement secure practices.

It's not Google's fault...

[overeduc8ed]

It's not Google's fault -- gmail is still in beta! :)

Re:

[huge]

Shame on them also?

Yes.

Even if there are others with the same problem doesn't give you excuse to ignore the problem.

Re:

[Svartalf]

Very MUCH the case.

Better yet, it proves out my premise that services such as these shouldn't be used for anything mission/business critical- PERIOD.

Well...Duh.

[SatanicPuppy]

Any decent-sized business would run into SOX problems if they used this sort of service consistently, and as a free service they have a very low duty toward their users. If gmail blew up tomorrow and Google decided to discontinue it, it'd be pretty difficult for any users to recover damages seeing as they weren't paying for anything.

Personally, I can't imagine using a non-guaranteed service for anything "mission-critical". If your mission relies on someone else's beta service, your business is in trouble.

Re:

[ScrewMaster]

Yes. In other words, lock your doors. It's as simple as that, and in the case of GMail it really is that simple. Add the goddamn 's'.

There are times I wonder about this generation. We don't really want to accept that we're responsible for much of anything. Suppose the Internet had been around fifty or sixty years ago. Ask your parents: would they expect to be mollycoddled by their ISPs and free services? I know my father wouldn't have ... if the Internet been around then odds are nobody would have breach

Re:Could be fixed easily by Google. Shame.

[AeroIllini]

The user must take responsibility for their own security.

Yet we turn around and lambaste Microsoft for allowing users to run as Administrator by default, having no-password logins, not locking down the registry, and allowing 3rd party developers to still require admin privileges just to run a userspace application.

The point is, security is more than just "what's available." It also has to be about how good the defaults are. The technical community cried foul when Microsoft included a firewall in Windows XP but didn't have it turned on by default, and we complained so much that in SP2 Microsoft finally changed the default.

I agree that security is ultimately the responsibility of the user, but they should not have to seek out secure settings and turn them all on one by one. The default mode for any network-enabled program should be Secure. If the user needs Insecure, then they should have to change a setting to make it so. Spam should be opt-in, security should be opt-out. Anything else is unfair to the user.

Re:

[teknopurge]

We have redirects setup on all plain-text channels that have a login to SSL, and have for the past 6 years; this is beyond common-sense.

Re:

[BewireNomali]

correct me if I'm wrong, but don't most who complain about microsoft OSes point to prior defaults to administrator privileges as a major security concern? If so, by that same reasoning, shouldn't web services default to more secure configurations as opposed to less?

Re:

[Wicko]

Is there a method to do this with Google's Personalized Homepage, as you can enable it to give you a preview of your email? I didn't see any options to change that.

lthough I guess I don't have much to worry about since we don't use wireless in our home.

Re:

[jumpingfred]

I have bookmarks for both gmail and my google home page
https://www.google.com/ig [google.com]
and
https://mail.google.com/mail/ [google.com]

Re:

[Wicko]

Hmm, I tried that but I get a warning from Firefox saying that unencrypted data is being used on an encrypted page, could be possible its refering to something else, like the slashdot RSS feeds or something. Not entirely sure how this all works.

Re:

[dr_d_19]

I fail to see how the average person, as usual, being lax about their security is in any way Google's fault.

Maybe because you can simply tie the session to the client IP adress and verify it during each request, which puts an end to the hijacking.

Re:

[awing0]

This won't work when you're on the same network as the attacker. That's the situation that was demonstrated here. There are a number of ways to spoof an IP address on an 802.11 network and have bidirectional communication. Add in the fact that you could be behind a NAT and you don't even need to go through the trouble.

Re:

[Electrum]

Maybe because you can simply tie the session to the client IP adress and verify it during each request, which puts an end to the hijacking.

Not with NAT, which is typically when you are most vulnerable (i.e. a shared wireless network).

Re:

[bberens]

When I go to my bank or credit card website I never bother to put the https as I'm typing the URL because they will always redirect me to a secure connection. It's a basic and common practice for services with important information. I would argue you shouldn't be putting important information on Google's web servers, but that still doesn't mean that they can't make a very simple change and dramatically increase the security of the data they hold.

Re:

[caseih]

Someone on PRI radio the other day pointed out that if Google defaulted to SSL for gmail, they would experience a server load that would be an order of magnitude more than they currently deal with. So I don't think that SSL is the answer here. What we need to find is a way to do a non-SSL session without a risk of the session being stolen. Perhaps some kind of light-weight cryptographic exchange on every request or something. A cookie that constantly changes and cannot be reused. Some way of making sur

Re:

[fbjon]

They shouldn't tell anyone, just transparently redirect to the secure URL. Sane defaults, and all that jazz. Or at least semi-transparently, with a "redirecting..." page that has a link to both encrypted and unencrypted login URLs, in case some network blocks https.

Re:

[fbjon]

That's the only reason I can think of why Google doesn't immediately send a 301 Permanently moved, and redirect to the https version.

Good reason to install Better GMail!

[Mr. X]

The Firefox extension forces GMail to always run over SSL. It's great! [lifehacker.com]

Re:Good reason to install Better GMail!

[afidel]

I think you should have linked to the Mozilla addons [mozilla.org] page. I know I wouldn't install a firefox addon from a random site with the name hacker in the URL.

Re:

[toad3k]

Yeah, but no one here has a life so they aren't in any danger. /ducks

Correct me if I'm wrong but

[trifish]

Even if you don't have encrypted transfer, session cookies can be easily secured by associating them with a certain IP address. The attacker who captures the cookies has a differnt IP address so the cookie is rejected as invalid. The only situation where this solution may get a bit annoying is if you're behind a load-balancing proxy, which changes your IP address on every request (fortunately, this is somewhat rare.) It's better than allow easy hijacks...

Re:Correct me if I'm wrong but

[Stile 65]

If the hijacker gets on your wireless AP, then he's NATed behind the same public IP address as you. Voila, he matches your IP. Another layer is to also fix the session cookie to the browser's UA string, but that won't work if the attacker knows you're doing it and changes his browser's UA string to match yours. In summary, secure your wireless AP if you're a user and buy some SSL acceleration hardware so you can support forcing all traffic on your website to use SSL if you're a service provider.

Re:

[TheRaven64]

Even if he's not NAT'd, if he's on the same WLAN then he's on the same broadcast segment as the real owner of the IP, so he can just send packets claiming to be from the legitimate user and run his interface in promiscuous mode to grab the replies.

Security is an application-layer problem.

[Kadin2048]

In summary, secure your wireless AP if you're a user and buy some SSL acceleration hardware so you can support forcing all traffic on your website to use SSL if you're a service provider.

I agree with the latter recommendation about using SSL, but saying 'secure your wireless AP' doesn't do a lot to help the many public wifi locations; I think it's unhealthy to ever assume that a wireless connection will be secure. As more wireless networks are rolled out, and more people get laptops with built-in wireless and traipse happily from home to their local coffeeshop, where they're sharing an IP and an unencrypted connection with many untrusted users, opportunities for sniffing and hijacking are only going to become more common.

As users demand more portability, security and authentication need to be moved (and kept) up at the application layer, and not simply assumed as part of the datalink or physical layers.

Security and the "mobile office"

[mcrbids]

I think it's unhealthy to ever assume that a wireless connection will be secure.

A few days ago my business partners and I were in some podunk town not far from Sacramento for a demonstration. The morning demonstration went well, but the potential customer was cool to buying, and so was kind of short. So there we were, all three of us, in some foreign town around lunch time. We found an ice cream shop that served sandwiches and had a wifi hotspot.

So we whipped out our laptops, took over a table, ordered some

Re:

[DeadboltX]

When you are sniffing wireless traffic you aren't actually associated with any access point. You simply open up your wireless card to receive all the 802.11 traffic floating around it.

Using WEP is just as bad as not using any security on your AP. If someone is savvy enough to sniff wireless traffic then they are savvy enough to crack your 128 bit WEP key in 10 minutes.

Re:

[trifish]

I've just read TFA and realised that all people in the room were sharing the same IP address, so what I described in parent post wouldn't help. The only thing they can do is force SSL to all requests.

Re:Correct me if I'm wrong but

[vidarlo]

Even if you don't have encrypted transfer, session cookies can be easily secured by associating them with a certain IP address. The attacker who captures the cookies has a differnt IP address so the cookie is rejected as invalid.

More often than not, all users of a wireless net is behind a NAT device, which makes all the devices have the same official IP. The same applies to most domestic, workplace and school wlans, so really, that would make little or no difference. Now, in a IPv6 world, it would make a difference, since everyone has a unique IP there...

Re:

[suv4x4]

Even if you don't have encrypted transfer, session cookies can be easily secured by associating them with a certain IP address. The attacker who captures the cookies has a differnt IP address so the cookie is rejected as invalid.

AOL dial-up which is relatively popular in USA (yea..) does this. Every request is on a different IP. Which is why many people don't do this.

It gets complex: you can not apply this fix to IP-ranges on AOL you know are used for dial-up. I also check the exact user agent string, of co

Firefox

[Sierpinski]

I don't have the extension that forces it to use SSL, but all you have to do to force the connection manually is add the 's' after http, and the session will reload under SSL. Hopefully you haven't already been compromised at that point.

I'm going to look for the Firefox extension now...

O RLY?

[Control Group]

I'm sure everyone's going to bitch about how Google should use SSL for everything. And from a marketing perspective, maybe they should.

But the openness of your wireless network really isn't their problem. You don't blame the banks if you shout your PIN out while you're at the ATM, do you? Or, more aptly, you don't blame the bank if you trust your ATM card and PIN to some stranger in a coffee shop.

It isn't Google's responsibility to secure your connection end-to-end. It's far more reasonable to think that it

Not the network's job.

[Kadin2048]

That's dumb. An application should never assume that the network it's connected to is secure. It doesn't matter whether you're plugged into switched Ethernet, a wireless LAN, or IP over carrier pigeon -- if you're designing an application that's going to transmit sensitive/assumed-private data (which email clearly is), it's a mistake to just blithely assume that the network is in any way secure.*

An application like Gmail should be treating all network connections as though they're unencrypted Wifi (or hubbe

Re:

[Jessta]

But you do blame the bank if the ATM you are entering your PIN at is insecure.

Having an open wireless network in the least of your troubles, I chance of someone in your area stiffing your packets in very small. The chance of someone stiffing your packets across the public internet is much higher.

I have an open wireless network, but all communication of a sensitive matter is transfered over HTTP or SSH, I really don't care if random people stiff my packets and read my slashdot.

Always use https://gmail.google.com

[StandardCell]

Although they don't have a public key scheme strong enough for the AES-256 (requires 15360-bit RSA or 256-bit ECC for public key), you should always be logging in using https://gmail.google.com/ [google.com] from all locations (even home) to ensure the entire session is encrypted.

Re:

[afidel]

Hmm, when I look at the page info and click on security in Firefox it says the connection is using AES-256. Do you mean they are reducing the effectiveness of the AES-256 session by having a relatively weak 1120 bit public key?

Re:

[StandardCell]

That's exactly the problem. Using RSA around the 1k-bit key strength is equivalent to 80 bits of symmetric key strength. AES-256 is a waste otherwise because all you need to do is attack the public key encryption to extract the symmetric key, and voila.

Re:

[StandardCell]

Sorry, that should've been 521-bit ECC since PK strength for ECC is half the number of bits.

ssl and gmai.

[jshriverWVU]

if you put a https instead of http for gmail.google.com it'll work. I dont understand why they don't do this by default if they already support it.

Re:

[pomerol]

Well, I suspect that the reason they don't serve GMail access over SSL by default is greed and/or the desire to be "green". Serving web content over SSL put significantly higher strain on servers. In Google's case this equates to more CPU cycles and that translates to higher power requirements. More power means higher costs for Google and more carbon emissions into Earth's atmosphere. I would like to believe that "do-no-evil" Google is doing this for the latter reason.

Re:

[Niten]

I don't know, I'm hesitant to believe that the decision to default to non-SSL connections in GMail resulted from some sort of ethical deliberation. It was probably just a matter of "we'd need to buy $X worth of hardware to support all our users connecting over SSL, so we don't see the benefit in providing this unless the customers really begin to demand it". In other words, just business as usual.

Re:

[prockcore]

I dont understand why they don't do this by default if they already support it.

Same reason the entire web isn't SSL by default. It takes a considerable amount of CPU compared with unencrypted web traffic.

Easy fix

[teslatug]

Bookmark the secure address and use that (who wouldn't over open wireless??). You could also use http://www.customizegoogle.com/ [customizegoogle.com] with Firefox if you're using Gmail to force it to go to the secure URL.

use gmail over https

[buddyglass]

Accessing http://gmail.google.com/ [google.com] will redirect you to a secure page for login, but after that you're back in plain text. If you start at https://gmail.google.com/ [google.com] then afaik the rest of your gmail session runs over SSL.

Make it default to https

[ajs318]

#  This is how I did it:
#
#  Actual snippet from my Apache configuration .....  mostly.
#  Some details have been changed to protect the innocent
#  And some details have been changed to protect the guilty
#
#  The virtual host "secure.mydomain.co.uk" cannot be accessed
#  by http; only by https.
#
#  The insecure port
<VirtualHost 10.11.12.13:80>
    ServerName secure.mydomain.co.uk
    DocumentRoot /var/www/
    <Directory /var/www/>
        RedirectMatch ^/[^iI] /insecure/
        # In this directory is a page with a dire warning
        # that https is required to access this server.
        # NB.  To avoid creating an infinite loop, we never
        # redirect if request begins with I or i.
    </Directory>
</VirtualHost>
#  The secure port
<VirtualHost 10.11.12.13:443>
    SSLEngine on
    .....
</VirtualHost>

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[Constantine XVI]

Apple has nothing at all to do with it.

Re:

[Amiga Lover]

Apple has nothing at all to do with it.

Wow, you guys are getting quick. One minute for a denialist to chime in. I'm impressed.

Re:

[Constantine XVI]

You do realize that GMail and Apple aren't related at all, right? The FA didn't even mention Apple. ...but I'm guessing you didn't read it. This is Slashdot, after all.

Re:

[fbjon]

That's the point!

Truly, an ingenious troll.

Re:

[Control Group]

I can't tell if this is the troll version of the long con, or if you've really got some sort of point about Apple, here.

If the former, I have to say, it's a well-played troll. If the latter, it would be nice if you got off your ass and made whatever devastating point you're so coyly alluding to.

rofl

[SatanicPuppy]

Ha! Come on, give it up for the troll, that was funny.

Re:

[Creepy]

well, at least Amiga is more secure against wireless IP packet sniffing and cookie stealing (yes, there is a wireless driver for Amiga).

oh wait, it isn't.

trolling today, are we?

Re:

[Kadin2048]

I think he's making a reference to this event [slashdot.org].

Re:

[jrumney]

Under server settings for your mail account, make sure either TLS or SSL is selected if you want to ensure that your connection is encrypted. I think TLS, if available is the default. On servers that support STARTTLS, this is OK, but it won't warn you if your server does not support it. Its better to try the forced TLS, and if you get an error, try SSL. If you have to switch back because your server does not support either, at least you know its insecure and can change your behaviour on insecure networks to

Re:

[jrumney]

If you can eavesdrop on session cookies, you can eavesdrop on any other plain text connection. Whoever modded the GP as Offtopic needs his head examined, as the vulnerability of other applications to the same attack is very relevant.

Re:

[Sancho]

More importantly, POP3 doesn't make use of cookies which can be intercepted. Although encrypting your entire web Gmail session would solve the problem, the attack works primarily because it's webmail.

Yes, it is.

[Kadin2048]

You're right that the exploit itself really isn't that new. What's new is twofold:

1) It's being done to Gmail, a service provided by People Who Should Know Better.
2) There is now a tool that allows any script kiddie to do it, meaning that it's no longer a theoretical exploit; it's something that your next-door neighbor is going to be doing to you (or your slightly less-technically-savvy family/friends) if you don't take precautions.

#2 is probably most significant, since it's really what's going to cause #1 to change. Sometimes, producing a GUIed, Windows-based exploit tool is the fastest way to get a problem fixed, because it's the easiest way to turn an academic argument into a real-world security issue that will get resources thrown at it. (Of course, it may also land you in jail.)

Re:psh

[Applekid]

Maybe not, but the heavenly smell is basically a SSID broadcast of their existance to those interested in finding them.

Re:thank god...

[Howitzer86]

I have never heard of anyone thanking God that they use Yahoo... in my entire life.

a Blackhat attendee not using a VPN?

[SuperBanana]

Please. Those guys are supposed to be security wizards! And now one of them is caught using plain HTTP to access gmail? I hope they laughed hard at him. Even securety noobs like me know when to use HTTP and HTTPS.

Um...the really smart people aren't using https. They're using http/https via VPN or SSH tunnel to a more trusted network.