Slashdot Mirror
Gmail Moves To HTTPS By Default
clone53421 writes "Although Gmail has long supported HTTPS as an option, Gmail announced their decision yesterday to switch everyone to HTTPS by default: 'We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data. Over the last few months, we've been researching the security/latency tradeoff and decided that turning https on for everyone was the right thing to do.' I wonder if this has anything to do with the reports of Chinese users having their accounts hacked? 'Only two Gmail accounts appear to have been accessed, and that activity was limited to account information (such as the date the account was created) and subject line, rather than the content of emails themselves,' said David Drummond in that blog update. That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers."
That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers."
If someone can intercept your traffic how will this help? They can intercept all your secret handshake bits too.
We need network neutrality for encrypted packets!
For the moment Google's own gadget for for iGoogle doesn't support HTTPS access to gmail.
Google couldn't really tell if there was sniffing going on in their users' connections. They could, however, figure out exactly what sort of activities someone using POP or IMAP or the web UI (or some compromised internal Google tool) ended up doing, based on logs.
The World Wide Web is dying. Soon, we shall have only the Internet.
Great move by Google, although TFA points out that there are some problems with offline gmail and HTTPS, kudos to them for coming straight out and saying it may be a problem, while posting a link for some workarounds: http://mail.google.com/support/bin/answer.py?hl=en&answer=172697
Q.E.D.
others sniffing the traffic they want to store for you on their end as to keep it all to themselves.
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
encrypted data doesn't travel across the web as quickly as unencrypted data.
Why on earth would that be? Routers don't know whether your data is encrypted or not. The one difference I can think of is that encrypted data can't be compressed. But that wouldn't have any effect on latency, just throughput. And that can be taken care of by compressing the data before you encrypt it anyway.
Give me Classic Slashdot or give me death!
Actually, I read somewhere that hackers gained access to a system designed to give law enforcement access to people's emails, presumably under warrant. [sarcasm]Who could have ever imagined the same loopholes intended for use by law enforcement could possibly be exploited by hackers as well?[/sarcasm]
"In prison you just have to shut your eyes and take it. Here you have to shut your eyes and give it."
I've long held that the only answer to pervasive surveillance is to encrypt everything.
It won't stop them from cracking things that attract their attention, but for most things it won't be worth the hassle.
Encrypt everything.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
I wonder if this has anything to do with the reports of Chinese users having their accounts hacked?
Really? No, I'm sure it's just a coincidence.
How do you kill that which has no life?
Unless you're entering your details via a virtual keyboard, using http or https won't make a damn bit of difference if you've got a keylogger running. (via trojan? I believe that's how the Chinese accounts were hacked)
Encrypt everything.
I agree, and let me add I always thought Freenet's model was onto something. It's very failure proof and it caches static content. Which unfortunately is everything. But there's probably a way to get something wiki-like using the current message board implementation, providing one had an application that could interpret the data from a dedicated board.
How do you kill that which has no life?
I've often wondered why email clients don't make it easier to set up encryption, and use it as the default if your recipient and you have exchanged keys (preferrably automatically if both have the capacity.) Sure, if you're semi-clued up it's not that hard to set this up manually, but to the average user it's way out of their comfort zone.
OK, better late then never. Good that Google has finally introduced HTTPS as a default.
Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google's data center. That way even Google employees cannot read our mail. Not for serving up ads. Not for any reason whatsoever.
And after that, Facebook and Twitter...
Nah, I'm dreaming.
I found the source. It's from PC World:
"In prison you just have to shut your eyes and take it. Here you have to shut your eyes and give it."
Apparently the two compromised accounts were because of "access a system used to help Google comply with search warrants by providing data on Google users." I've blogged about this. And my source for all of that is from an article in Computer World.
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
The initial slow down because of the encryption overhead will eventually be compensated for with faster networking hardware and technology so it isn't such a burden.
In the long run it will be better.
Anyone care to guess if Yahoo! will so the same thing?
I really hope so. I use a Yahoo account and I know how easy it is to sniff Ethernet. I hate to read mail at cafes and other places where I'm not certain of the LAN security.
Encryption has some overhead, but so what? It's not like modern hardware isn't up to it.
Anybody who cares about security has stopped using open protocols to send sensitive data. FTP is out, SFTP is in. Goodbye Telnet, hello SSH. And anybody who sends passwords over an open HTTP, SMTP, or IMAP connection is begging to be hacked. (POP? You're still using POP?) The issue is not security versus performance, it's the usual case of people not going to the trouble of upgrading their technology until they can't ignore the problem any more.
As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues, or making sure you the resources to properly support your latest product. They need to hire fewer geniuses and start hiring more ordinary drudges with the patience to make things work in the real world.
if you want encryption, encrypt your email. Encrypting the connection between you and your smtp/pop server doesn't change the fact that the message is not encrypted when stored on the server or sent between hosts.
That said, I have been using gmail over https because I often check it using free wifi and damned if I know what kind of logging, packet inspection, or html modification might be going on.
Do you even lift?
These aren't the 'roids you're looking for.
Not much point with gmail though. If the power that be wanted access to your account they would simply look up Google's "lawful interception" pricelist and pay them the $40.
The spooks in government and private industry (hi IT dept, snoop anything juicy recently?) don't want encrypted traffic to become the norm. They have the ear of their respective leaders, so I wouldn't expect the status quo to be changing anytime soon. The plebs don't even realize what they've given up.
(Posted using my work computer via unencrypted HTTP piped through an SSH tunnel)
'We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data.'
Huh? Encrypted bits are asthmatic and can't run as fast as unencrypted ones? Coming from someone at Google this statement is quite the WTF. Is it too technical now to say that encrypting data requires extra calculations which introduce delays so gmail will respond somewhat slower?
I deal with the vast unwashed neo-luddites who are happy with their on button and cup holder. They can with some effort open and read emails. Asking them to manage a secure public key system is beyond their fragile minds. At least their mail is harder to hack.
Having terrified them that they would lose everything including pension if they did anything with banking or 401k or bought anything at least my parents are safe.
Though to my dismay they used a debit card for the first time last year. When they told it to me you'd think they'd survived the Donner party.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
I'd think someone would have done this analysis for all types of data. Can someone on Slashdot point us to those studies ? Mapping the delay times to user experience may be the missing link but surely some study indicating how decryption/encryption processing will delay response times.
why is it that if I have an account like
bob.alice@gmail.com
That mail addressed to
bobalice@gmail.com
gets delivered to bob.alice@gmail.com
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
sadly freenet is empty if you dont count the pedophile....
No, if that were the case they would have been able to see *everything* the user received as part of the data response, including message bodies.
Omeganon
I don't know, I think there are some things that don't need encryption. I don't think I will ever need encryption to read google news, for example, or to watch youtube movies.
Qxe4
Some free mail providers have been offering HTTPS for a long time, for example the Russian https://www.pochta.ru/ . Their web mail interface is decent too. Unfortunately they've been bought out by or merged with "qip" and have dropped their English language option since. It's still usable though and a good option if you need a free mail account with secure authentication outside of the western countries for some reason.
1a - If your email is encrypted with IPSEC, then there's a per-packet overhead from the extra packet header; it's not really a percentage, though you could think of it that way for average packet sizes. It's not significant for most applications except VOIP, which typically has very small data wrapped in lots of RTP/UDP/IPSEC/IP headers.
1b - If your email is encrypted at or above the transport layer, there's typically minimal overhead. The data encryption doesn't take extra space, except sometimes for the last packet of a session which might not contain a full block of plaintext so it gets padded by a few bytes.
1c - There's typically some setup overhead for key exchange. It doesn't take much transmission time unless you're on some funky very-low-bit-rate transmission medium, but there can be a couple of RTTs and some public-key math calculation time. So maybe it takes an extra second for you to start Gmail - big deal.
2 - That's why you compress the data *before* encrypting. Not many people use compressed transmission systems these days (e.g. fancy WAN optimizer tricks), and if anybody's still using SLIP or PPP with header compression, it doesn't care about HTTPS vs HTTP because that's not a Layer 1/2/3 problem.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Google probably only (at least intentionally) offers that service to governments. So while it might not protect you from the biggest threats out there, there sure as hell would be a point to it.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The day someone implements DNSSEC based server key delivery in a popular browser, there will be a grass-roots effort to make your dream come true.
...if you begin with the right URL.
Thank you, Edward Snowden.
"Arguments from authority are worthless." —Carl Sagan
I removed the Gmail gadget for iGoogle from my iGoogle homepage, because despite the iGoogle being loaded via HTTPS, the Gmail gadget would use plain HTTP.
Have they changed the Gmail Gadget to also use HTTPS? I couldn't find anything about it.
Edith Keeler Must Die
Dont’ you mean IMAPS and SSMTP?
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Maybe you don't want that cute barista (who is also a geek and watches coffee-shop router traffic for fun) to know you are watching a Taylor Swift video?
"Only two Gmail accounts appear to have been accessed"... by attacking Google systems directly. Using other methods, the attackers were highly successful.
Google disclosed that upon investigating users suspected of being attacked, they found "dozens" of Chinese human rights activists who had been compromised through phishing, malware or other systems that allowed security forces (presumably) to read their mail via a valid authentication. So, while Google itself may be mostly reliable on the backend, the security ecosystem as a whole is deeply flawed.
Google: "as part of this investigation but independent of the attack on Google, we have discovered that the accounts of dozens of U.S.-, China- and Europe-based Gmail users who are advocates of human rights in China appear to have been routinely accessed by third parties. These accounts have not been accessed through any security breach at Google, but most likely via phishing scams or malware placed on the users' computers."
http://googleblog.blogspot.com/2010/01/new-approach-to-china.html
So go change your passwords.
Since when is HTTP(S) “everything”? Maybe for those who have never seen something else than HTML and webapps.
Just set up VPN-like connections. Or think it to the end, and use a Darknet by default. ;)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Is it obvious to everybody that encrypting everything is good only for privacy but doesn't seem to add much to security when compared to encrypting just the authentication data then using a session ID? Or rather, could the gurus please clarify where's the security increase in putting everything over https?
http://dilbert.com/2010-12-13
encrypted data doesn't travel across the web as quickly as unencrypted data
That just hurts my brain.
I don't know, I think there are some things that don't need encryption. I don't think I will ever need encryption to read google news, for example, or to watch youtube movies.
Actually yes you need to encrypt that too.
If you are selective about what you encrypt, then the best assumption to make is that the things you don't want/need to hide are plain text, and the things you want/need to hide are encrypted.
Now when I am watching your data stream and see some google news, a youtube video, and finally an encrypted block of data, it is almost certain that whatever is in that encrypted block of data is worth my while to try and crack, as it is clearly data you want hidden.
If you encrypt everything all the time, then I would always wonder what you are hiding (if anything!)
I could take some of your encrypted data and try to crack it. Say it works once or twice, and all I see are you reading your daily news, and some video of a kitten falling over on youtube. Well hell, suddenly not only did I waste a lot of time cracking that encryption for nothing, but I would assume (possibly mistakenly) that you very well might not have anything to hide, and there is no reason to specifically look into anything you are doing.
Even if I don't assume that, and either assume or just know that you DO have something to hide... Well as a hacker, where would I start? I don't have all the time and processing power in the world to brute force everything you do. I would always be very behind your 'now' traffic. By the time I eventually did get to decrypting the part you really wanted hidden, it could be years or decades later. How much use would that data be so long after the fact? More often than not, the older the data, the less useful it is.
Encrypt everything. Nothing looks suspicious and out of the norm, so if/when you do something that you do want/need hidden from hackers, a hacker wouldn't even know it happened let alone know where to start looking for it.
Not encrypting everything just paints a huge target on the exact data you are wanting to hide in the first place.
GMail items still shows up on my Blackberry, and that's all I care about. If I need to write a long email then I'll log onto the computer.
I don't notice the speed difference at all.
How big an effort is that to do in, say, WebKit? Firefox? Why isn't anyone working on it? Or are people? What are the benefits?
Forgive my ignorance, I truly didn't know. Is it something that a few thousand dollars of programming time would buy?
You've got to be kidding.....
Qxe4
If the encryption is that easily crackable, then it signals a need for increased encryption. What you are advocating is security through obscurity. Sorry.
Qxe4
How about some love for Google Groups? They're currently overrun with spammers who are bypassing all available moderation measures.
How do you effectively search your email history if it's all encrypted? Are there algorithms for indexing encrypted data without giving too much away?
If they make Google Apps HTTPS only, I'll be screwed, because my little embedded devices can't handle HTTPS stack.
We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data.
Bullshit.
Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster. That would be why it's taken until now for them to take this step.
Of course, it's still fairly useless if I stay logged in -- then my session could still be hijacked from vanilla Google searches...
Don't thank God, thank a doctor!
It isn't terribly complicated, but of course it's security sensitive code, so it would need to be done really well. The bigger stumble block however is that it would form a standard (by implementation) or that it would have to adhere to a defined standard, which means there can not be ad hoc implementations. The DNSSEC data should probably augment self-signed certificates instead of going a completely separate way, so that there would not need to be changes to the web server.
I really want EVERY site I visit to use https. Why doesn't slashdot?
Just another "Cubible(sic) Joe" 2 17 3061
The standard e-mail addressing scheme for nearly all institutions is firstname.lastname@blahblah... It is most certainly valid.
Google just - being a service where anyone can register - wanted to ignore dots so that johnsmit@gmail couldn't impersonate john.smith@gmail and the other way around. In addition, google only allows a-z, . and 0-9, so you can't register john-smith@gmail, john_smith@gmail... etc... You actually need to have different letters and number combination than anyone else.
Purge logs within a reasonable time since making the last octet of IP is not really making the log anonymous.
Do not store IPs in any of the search logs. I still have not figured out why Google does it. Aside from geographical information and abuse detection you can't really use IP anything, unless you want to provide information to authorities.
Expire Google cookie each week.
Provide an anonymous proxy with limited search capabilities. That way people who really care can get their top 10-20 results while the rest of us can enjoy more garbage and ads :)
Stop any self-sensoring. Information is out there to be free.
Put up information on how to make searches anonymous, e.g. how to use TOR, privoxy and other secure tools.
Encrypting all traffic is actually a great way to ensure net neutrality.
Correct, I meant using WiFi with my own laptop (a MacBook).
I can use a secure OS. I can use a secure browser (Firefox). But if I can't use a secure LAN, I need transport layer security (SSL). For that, I'm at the mercy of the web site, or e-mail provider, that I'm connected to.
I wish that the end user, not the service provider, had control over transport layer security. Let me make the choice of security over performance.
A more important aspect is that everybody should use encryption. Singling out people for using encryption is a bigger threat than singling out encrypted data. As long as the encryption is good quality, "they" can't break the encryption, but "they" can break people. Encrypting everything makes mass-surveillance impractical.
https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data
Reference please? How would encrypted data travel any different than unencrypted date? Routers don't look at content and the difference in payload sizes is negligible.
Perhaps the poster is assuming the CPU required for encryption/decryption will slow the message down but we're talking about milliseconds, nothing that rises to the level of human perception.
Honestly have to wonder whether the OP is a Yahoo!, Compuserv, or AOL employee, given how out-of-date those companies' email and webmail offerings have become. Everyone else converted to HTTPS webmail and IMAP/POP over SSL/TLS long ago.
And you're advocating security through magic? I fail to see where he suggested using weak encryption. The security conscious tend to assume "opponents" of nearly unlimited resources, and in that scenario any encryption can be cracked.
Depends on whether you want to squick em by searching for Chocolates, Roses, Dog Biscuits, Leashes and Hand/Ankle Cuffs.
Mod me up/Mod me down: I wont frown as I've no crown
Encryption has some overhead, but so what? It's not like modern hardware isn't up to it.
We recently bought servers with their cryptography performance as a huge factor in our decision. The primary math operation required for SSL, modular exponentiation, is extremely expensive in CPU use. It is still the #1 item on CPU profiling charts for the servers.
We actually went to 64-bit just to get the 2x~3x modular exponentiation performance it provides.
Also, this CPU cost won't really go down: if you can buy faster machines, so can the crackers. So you increase the key size.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Unencrypted content can be proxied, encrypted content cannot. Sure, the mail is dynamic, but images on the backround aren't.
Still, it's only a minor point.
The more likely issue is that encrypting about 2 gazillion responses a day for all gmail users worldwide would be a significant impact on their webserver's CPUs.
You are exactly right. This is for the very same reason that we need to start making encryption standard for everyone; if your scenario was to take place under current circumstances, you would already be under suspicion and under greater focus since most people don't encrypt everything... when everyone encrypts everything, it will finally be the case that no pattern can be deduced from the presence of encrypted data
> Not encrypting everything just paints a huge target on the exact data you
> are wanting to hide in the first place.
Right. So just encrypt the kitten videos and send lots of tantalizing stuff in the clear. That'll fix 'em.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
When will Google provide S/MIME support natively?
since encrypted data doesn't travel across the web as quickly as unencrypted data.
It's probably because of all the extra 1's. They're heavier.
No, seriously, this statement is bovine excrement.
What is true is that encrypted transactions (from SYN to FIN) are slower than unencrypted ones because they transmit more data in more packets using more roundtrips.
Of course, that's not what you tell the (crypto-illiterate) public. But wouldn't "accessing web pages with HTTPS is typically slower than with HTTP" convey exactly the same information to the public, except for the wrong part?
Reference please? How would encrypted data travel any different than unencrypted date? Routers don't look at content and the difference in payload sizes is negligible.
This might have to do with compression as well as the key exchange/processing overhead.
I remember my university lecturer explaining that written English text could be compressed down to about 1 bit per character, and this was to do with the fact that patterns of written text are quite common. I would imagine that the same principle holds reasonably true for HTML as well.
Encrypted traffic essentially looks like a sequence of random bytes, so probably requires 7 or 8 bits per character.
I expect that multiple links along the route will try to compress your data to save bandwidth where they can (the first modem being a prime example), and in the case of https, no compression can be done.
Yeah, so if I'm right (sorry, no references), Reading an email could easily be 7-8 times slower over https.
How would encrypted data travel any different than unencrypted date?
You would have more roundtrips during the key exchange phase of SSL. It's not that the data travels slower, it's that there is more of it, and you have to wait for more ping-pong iterations.
I've long held that the only answer to pervasive surveillance is to encrypt everything.
Law enforcement and broadband providers aren't going to like that. Ubiquitous encryption shoots down their "argument" that only criminals would encrypt their traffic.
To-do List: Receive telemarketing call during a tornado warning. Check.
Don't forget that active ad injection "services" that drop in ads (or merely add cross site traking stuff) are going to be more and more common as ISPs try to keep their quarterly numbers up, but not lay fiber.
Even just a way to have packets signed in a way that an active MITM attack would be noticed (because of SSL's overhead) would help to keep this form of intrusion from becoming a common issue.
Unfortunately no, because the attacker can still see where the packet originated and where it's going. You'd need to combine encryption with onion routing to prevent that. Mind you, using encryption whenever it's available is still a good idea in this age where Lidless Eye seems to be everywhere...
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
I've long held that the only answer to pervasive surveillance is to encrypt everything.
It won't stop them from cracking things that attract their attention, but for most things it won't be worth the hassle.
Encrypting only some things will draw attention to them, it can also leak information. e.g. communications between alice and bob are encrypted, but not between alice and cath...
In the same way if you are going to shred documents it's a good idea to shred everything. Even try and ensure that shredded "confidential documents" are well mixed with shredded "junk documents".
Someday Google will be larger than even China, and then nobody will dare mess with their servers.
That is complete bull... Data is data (1's and 0's) and it travels with the same speed regardless of what those bit represent.
The correct way of saying what the author intended to say is something like this: "https can make your mail slower compared to unencrypted http since encrypted data requires some additional overhead and some additional processing power to encrypt and decrypt at each end".
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
one-time pads can't be cracked...
There is a free certificate authority: http://www.cacert.org/ . Unfortunately, it's not "official", but the root certificate is installed by default on a lot of free systems. (see ca-certificates package in Debian) I'm sure slashdot users are techy enough to understand it.
Of course, you can immediately discard any useful thing being in traffic from Youtube - unless the hacker is desperately short of crummy user provided content and comments that make the raptor jesus cry. They can discard anything from news sites too - particularly since you can just read the comments on each news article you look at via the url. Really, it's only sites that provide private information that can't be filtered from their 'look at' list. Sites like your email, forums (assuming they care what you write in semi-public places), your banking (which is already heavily encrypted). Actually, if it's really important and needs encrypting it probably is already.
All those moments will be lost in time, like tears in rain.
I think there are but this is such a complex topic that I don't understand what is and what is not possible.
Chinese government requires installation of special CA bundle on all computers in China. :)
Can't speak for gmail as I've never used it but my online banking is enormously quicker with images turned off.
Takes 27-30 seconds to display a page with images turned on. Takes 3-4 seconds with it turned off.
Unfortunately there are a few things that cannot be done without images turned on. :-(
(natwest one account)
Infact, so dire are most bank websites that I'm amazed that browsers don't yet have an option to turn on caching for images over https.
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
That’s exactly why I do like it.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Reference please? How would encrypted data travel any different than unencrypted date? Routers don't look at content and the difference in payload sizes is negligible.
It takes longer to establish an HTTPS connection than an HTTP connection. It also requires encryption on the server and decryption on the client, both of which take a little extra time. Finally, encrypted data doesn’t compress well at all, and data is normally compressed as it is sent over the internet. With HTTPS traffic the encryption happens first and so the compression isn’t effective.
Plus some ISPs try to get away with prioritizing HTTPS traffic lower than HTTP traffic, or they just throttle it altogether, since it’s probably them damn file sharers encrypting their traffic so we can’t tell what they’re downloading.
Perhaps the poster is assuming the CPU required for encryption/decryption will slow the message down but we're talking about milliseconds, nothing that rises to the level of human perception.
First of all, I’m the poster, and that quotation wasn’t mine. It was a quotation from the Gmail blog, and I had it nicely set out in its own blockquoted paragraph until Timothy moved it all into one paragraph. Now it’s set off in single quotes, which makes it blend into what I wrote.
Yes, we’re talking about milliseconds, and most users wouldn’t notice. However, on the server’s end, we’re talking about thousands or millions of users, which adds up to thousands or millions of milliseconds, which makes their servers slower on the whole, which the users may be able to notice. So it may be a case where if a few users enabled it, the slowdown would be imperceptible, but if all their users were using it, the load on their servers would slow everyone down to a noticeable sluggishness.
Honestly have to wonder whether the OP is a Yahoo!, Compuserv, or AOL employee, given how out-of-date those companies' email and webmail offerings have become. Everyone else converted to HTTPS webmail and IMAP/POP over SSL/TLS long ago.
Everyone else converted to HTTPS webmail, you say? Who exactly do you mean by “everyone else”? The login will always be done securely, but once you are logged in it will typically switch to an unencrypted session.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
If the encryption is that easily crackable, then it signals a need for increased encryption. What you are advocating is security through obscurity. Sorry.
There is nothing wrong with security through obscurity, as long as that isn't your ONLY security.
In addition, you are correct in that current encryption is difficult to crack.
It takes a lot of computing resources and time. Plus access to the stream of encrypted data.
I offer no argument at all that being targeted in this way is likely, only possible.
As one far extreme (that really is a bad example): I would postulate that most 1st world governments DO have the resources do crack encryption given enough time. As their resources are expanded, the amount of time shrinks.
However they also have time to spend. I would almost be willing to say "If the government wants your encrypted data, they WILL get it"
Now, of course that is a horrible example since most governments wouldn't bother brute forcing your encryption if you happen to live in the same country as that government. They will simply arrest/disappear you, and beat you until you give them working decryption keys.
The other end of the extreme would be Johnny script kiddie in his moms basement. This kid does NOT have limitless resources of his own, however it is probably safe to say he has plenty of time and nothing better to do with his life.
Unless you do really stupid things, this attacker should not be able to brute force your encryption before his own death.
However there is a HUGE area of attackers somewhere in the middle. I would rather not make assumptions about other groups time and processing power, and instead would prefer to assume the worst and plan ahead for that.
If the worst happens, I'd be ready. If not, oh well, the goal is still achieved even if some effort was spent that didn't need to be.
As a final thought, even johnny script kiddie might be a decent threat.
You know he doesn't have a super computer cluster in his basement, however he may very well have (or have access to) a large botnet of compromised machines that possibly could raise the available computing power to 'enough' to be a threat.
There is no 'line' to cross where encryption turns from strong to weak.
Encryption methods and key size just determines how long it would take to brute force.
Sometimes this number is low and measured in seconds, other times it is very high and measured in centuries. This number always goes down over time as computing power increases.
All you can hope for is the length of time it would take to break your strong flawless encryption is greater than the time you need the data to remain secret.
It is not obscurity, it is simply the fact of how encryption works.
The barista grapevine tells me that you've been watching stuff weirder than Taylor Swift, dude. If you're going to stream American Idol, at least put the sound through headphones so as not to subject the rest of us to it!
Note: I was 13 when I wrote most of this. Take with several grains of salt.
stopping the rest of world from lawful interception
Afaict the killer is the round trip times, a ssl connection takes more round trips to set up than a plain TCP one and web browsers frequently set up new connections (yes there is keepalive but thats still a far cry from a system that uses a single persistant connection).
No problem if you are on a fast low latency connection but if you aren't those extra round trips can really add up.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register