I'm wandering why you say that. Of course it matters if it's https or not. If https can be broken then it's much more dangerous to send it over the internet at large. It simply couldn't be used.

AFAIK https using SSLv3 is impossible to break at the moment. That's what ebay uses for example. Https using SSLv2 also has some defficiencies but you need quite good knowledge to intercept anything.

WEP is broken in around 3 minutes.

Don't use http for sensitive information. I snoop on my neighboors, he's browsing porn websites. Bad taste (s)he has

I use wep (my gateway is a laptop not supporting managed and then wpa2) but https on top of it. The rest I don't care.

That's the thing, https can be decrypted. The question is, does (insert who ever's wifi connection you're using here) do it? That's one of the big problems with wifi. You have absolutely no idea where that access point you're connecting to is. It might be the Starbucks access point you connect to every day at lunch, it might also be that "delivery" van out in the parking lot with an access point set up to look like Startbucks with a 5 watt amp. Most people's laptops will connect to the strongest signal, the dude in the van now has the strongest signal. All he has to do is set up a bridge to the real Starbucks and capture all the traffic. There might be a small hicup in the connection when he starts up his rig, but most people won't notice the difference. The one's that do will make some curse to Microsoft, and reconnect.

Even with this kind of spoofing of your WiFi connection, how does this help the 'attacker' decrypt your SSL encrypted data? Unless he has offered up a bogus secure server certificate which you then unwisely accepted despite all the browser warnings, HTTPS is generally considered to be secure (if it wasn't, internet commerce would collapse overnight). Passing confidential data over HTTP connections (wired or wireless, WEP or WPA) is not clever, but absolutely fine over a properly authenticated HTTPS connection with a valid certificate.

Did you look at the link I posted earlier? That's what I'm talking about. You're basic internet user won't know the difference between an authentic ssl cert and a spoofed one. At least with a wired internet connection you have a pretty good idea of where your packets are going.

I've also seen hardware that can decrypt ssl connections in real time for wired connections. I just can't seem to find it at the moment. They are set up for wired network security boxes to check for viruses and whatnot, but they can be used for whatever you want.

The point is HTTPS *is* secure and the connection medium is irrelevant (my wired ADSL connnection can easily be sniffed at the exchange). If a user blindly accepts an invalid certificate, that isn't the fault of SSL/HTTPS - sometimes there is nothing that can be done to protect the really stupid.

Sure, if they have the private key used to initiate the connection and also have the resulting shared secret but what's so special about that? If you're suggesting there are machines capable of decrytping SSL encrypted communication without the aid of the original keys and shared secrets then I would be very, very surpised (as would the NSA, unless it's their machines but then I doubt they would publicise that fact!) SSL 128-bit is very hard to crack on the fly, and next to impossible using brute force - by the time the key has been discovered (several years computational effort) the importance of the message is long since degraded. Lower level SSL encryption such as 40-bit encryption is theoretically possible to crack using brute force in the space of several hundred hours with several hundred computers. But not real time.

Yea, I see your point. I'm just saying I know there's network hardware out there that transparently decrypts, checks for stuff not allowed on your network, then re-encrypts https data. I just can't find it at the moment.

Damn!! You type fast. No, they get the initial keys, I don't know of anything that does it without them.

Interesting, because the HTTPS connection uses a shared secret that is encrypted by the browser using a public key from the remote server such that the shared secret (used to encrypt all subsequent communication synchronously rather than asynchronously) can only be decrypted by the remote server which houses the private key. So any intermediate servers must have access to the private key used by the remote server in order to decrypt and observe the shared secret in order to decrypt the communication in real time, and if this is the case it's a major security breach. Either that, or the intermediate servers are spoofing the entire SSL session and providing their own certificate to the browser in place of the remote server, and maintaining the session so that the correct shared secret is used when forwarding to the remote server - tricky, and it may be possible but I would still expect the browser to barf when it gets the intermediate servers certificate when it is expecting the certificate for amazon.com!

There are of course devices (firewalls, proxies etc.) which can and do analyse HTTPS traffic without decrypting the data because the HTTP headers themselves are never encrypted, only the payload is encrypted using SSL.

Load balancing hardware such as BigIP servers offer "SSL termination" (aka hardware accelerated SSL encryption/decryption) however these servers are designed to be used in an situation where they front-end the servers that are hosting the secure service in which case it would be correct to configure the load balancers with the public/private keys for the "remote" server (which would be on the same LAN behind the BigIP servers). Maybe this is the situation you are referring to, although there isn't really any need to re-encrypt the messages once decrypted by the BigIP servers as the now decrypted messages would normally be forwarded on to the remote servers over a private (and hard to sniff) network.

Milhouse described HTTPS security well, so I won't go into details about it myself.

The only currently known wi-fi semi-specific problem you can run into with HTTPS security is the one I described in my posting: The scam where someone sets up a fake pay-hotspot, to e.g. look like a T-mobile hotspot or your local airport hotspot, and you get access by entering your credit card credentials. For any other kind of wi-fi network, where you *don't* "log in" as described, there is no known security risk with HTTPS that isn't already in existence in the internet in general. As I already said, a wi-fi network is available to a handful, the general internet to millions.

And no, it's not true that with the (wired) internet you have a good idea where your packets are going, wi-fi or not isn't the issue. Fake sites with false certificates are on the wired internet (and naturally so -- that's where there's a billion potential victims). As for breaking HTTPS (except the old, poor 40-bit encrypton) it's not considered easy. There are much easier ways to scam you.

As for anything important you do on the network: If you connect to your bank, and the browser complains about the certificate, don't click 'continue anyway'. Leave the site. If you don't, you lose. Whatever network your'e on.