From the view of somebody offering a web application, when somebody connects with TLS (https) to our service and submits the correct authentication data, is it safe to transmit all sensitive data over this line, or can it be that there is still eavesdropping?
This question was IT Security Question of the Week.
Read the Jul 29, 2011 blog entry for more details or submit your own Question of the Week.
It's important to understand what SSL does and does not do, especially since this is a very common source of misunderstanding.
So, the quick answer should be: "yes, it is secure enough to transmit sensitive data". However, things are not that simple.
So, shorter answer? Yes, SSL can be secure enough, but (as with most things) it depends how you use it. :)
SSL 2.0 was deprecated (prohibited) in 2011 ... / SSL 3.0 was deprecated in June 2015 ...
There are a few issues here, the major one being authentication. Both ends need to be sure they are talking to the right person or institution to thwart man-in-the-middle attacks. On your end it is crucial that you use an SSL certificate which is trusted by the user's browser. By doing so the user's browser can be sure that it is really talking to the correct site. Once the connection is established you can be sure to be talking to that user all the time and the connection is encrypted, i.e. secure against eavesdropping.
Authentication in the other direction (i.e. making sure you are talking to the real user) is usually handled outside of the SSL protocol on the application level by, e.g., username/password, openID or some other form of credentials.
As a last note it should be mentioned that during the SSL connection handshake client and server agree on a Cipher suite and the client could pretend to only do "null encryption", i.e., not encrypt any of the data. If your server agrees to that option, the connection uses SSL, but data is still not encrypted. This is not an issue in practice since server implementations usually do not offer the null cipher as an option.
In addition to what AviD lists out, SSL is only as secure as the DNS infrastructure that directed you to that server, and any corporate proxies in the communication path.
If the DNS infrastructure is hacked (cache poisoning, etc) then the attacker could subject your user to many attacks.
In addition if the client is going through software like Fiddler, or a corporate proxy, that software can easvdrop on your SSL conversation.
To mitigate this, look at the "issuer" of the SSL certificate. If the SSL connection is going through a proxy, then the issuer will be that of the proxy. If you're going through a direct connection, then you will see the relevant publicly trusted CA.
[More information]
A corporate HTTPS proxy is something that manages the connection between the web browser and the Proxy (whose IP address appears in your webserver logs). In that case the web content (HTTPS password too) is decrypted, and later re-encrypted at the corporate proxy and presented to your server.
Depending on who is managing the proxy, and how its logs are used, this may be acceptable or a bad thing from your perspective.
For more information on how SSL interception is done, see this link:
When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the client browser. The client browser issues a security pop-up to the end-user because the browser does not trust the issuer used by the ProxySG. This pop-up does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in the client browser's certificate store.
The ProxySG makes all configured certificates available for download via its management console. You can ask end users to download the issuer certificate through Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated certificates...
Some companies get around the certificate pop-up issue mentioned above by deploying the root certificates (of the Proxy) to each workstation via GPO. Although this will only affect software that uses the Microsoft Certificate store. Software such as Firefox and Chrome needs to be updated differently.
As SSL relies on Certificate-Authorities (CA), and basically any organization can become a CA, man-in-the-middle attacks with fake yet CA-signed certificates are always possible. So while SSL is still a huge improvement over not encryption at all, its security is overrated due to the broken CA system. In that regard, self-signed certificates would be just as secure as any CA-signed certificate, yet browsers mark those as suspicious.
SSL is very secure, although someone can steal someone's session cookie if you run ANY page over a unencrypted line. If you could I would make the site all-SSL. Or possibly have the cookie only send for encrypted connections and have unsecured public pages not specific to that user.
There is still the possibility of a man-in-the-middle attack, which in your case would be the user connecting to a third party claiming to be your site and then forwarding the request. Of course, a savvy user should notice the lack of an SSL connection or the wrong certificate but most users are not this switched on and get duped by a padlock favicon.
This isn't really an issue with SSL itself, just something to be aware of. You can safely assume that no-one is able to eavesdrop on the SSL connection between your site and the source of the connection. You can't, however, be sure that the source of the connection is really the user.
Since SSL crypts the transmission, no data can be eavesdropped (since the certificate is trusted).
Altough the problem reside on where (and how much) you are using SSL in your webapp: say, for example, you require an SSL connection only to authenticate your user (to let 'em send they crypted user/pass pairs to your server), then when you send back a cookie you should be aware that it could be easily intercepted (like if your user is on an unprotected wireless connection).
The recent FireSheep drama is all about this.
No. Traffic analysis can still tell someone a lot.
Traffic analysis is the process of intercepting and examining messages in order to deduce information from patterns in communication. It can be performed even when the messages are encrypted and cannot be decrypted. In general, the greater the number of messages observed, or even intercepted and stored, the more can be inferred from the traffic.
TLS is usually deployed to preserve confidentiality -- an attacker should not reach a high level of confidence about the contents of communication.
Assuming,
An attacker can probably tell when you are awake and when you are asleep regardless of protocol, and may be able to tell a lot more depending on the nature of the protocol you're using.
If your protocol is very simple:
An eavesdropper who can't decrypt your data can determine by the mere presence of a message that you want to fire nukes, though maybe not at whom.
If your protocol is more complex:
An attacker may not be able to tell who is reading "War and Peace" vs "Atlas Shrugged" but can distinguish, based purely on message size, whether they are reading one of the former vs. Kafka's 55 page novel "The Metamorphosis".
SSL performs two basic tasks: authentication and encryption.
Authentication is done by means of certificate authorities (CAs). Browsers come with a list of SSL certs for for the signing keys of the CAs. CAs sign certificates that describe the public key of an entity. For example, if I owned Google.com, I'd prove that to Verisign and they would sign my certificate for some period of time. Problems crop up with a CA signs a cert they shouldn't sign. This can occur when somebody pretends to own another domain, acquires a wildcard cert that is too broad, or just plain XKCDs the CA into issuing something nefarious (governments, perhaps?). We've seen instances of all of the above happen, but it is pretty rare.
If a cert for a site is properly signed and no fake cert in your trust chain exists, then when you connect to a site you can (for discussion purposes) be confident that the certificate matches. Under normal circumstances, that connection is encrypted. That prevents anybody from reading your data.
SSL certificates are very complex, and a number of attacks exist against SSL implementations. What SSL can effectively do is prevent me from watching your traffic at the local Starbucks when you check your email on GMail. What it can't do is prevent me from using a MITM attack where I relay everything to you without SSL and your client isn't setup to bother you about the fact that never started an encrypted session.
Not counting the various answers by others about other potential issues, assuming you are using SSL 3.0 and strong encryption, it should be secure.
Using older ssl protocols (2.0) or using a weak encryption key could open you up to vulnerabilities.
SSL generally increases security by providing:
There are essentially just two types of SSL certificate, the server certificate (which is always involved) and a client certificate (which is optional).
This is just a sketch, and there are many ifs, ands and buts. In the most typical scenario, browser based SSL, the scheme can broken in many cases without breaking the cryptography or the protocol, but simply by relying on the user to do the wrong thing (i.e. ignore the browser warnings and connects anyhow). Phishing attacks can also work by sending the user to a fake SSL protected site, made up to resemble the real one in all respects but the URL.
Having said that SSL and its cousin TLS are still very useful as they at least allow for secure communication, albeit far from foolproof.
When somebody connects with SSL (https) to our service and submits the correct authentication data, is it safe to transmit all sensitive data over this line, or can it be that there is still eavesdropping?
The weak link in this chain is almost certainly not SSL but the user, who can generally be tricked into connecting to a fake intermediate site either via web spoofing/hyperlink spoofing, or by being presented an invalid certificate and dismissing the browser warning and proceeding to connect anyway.
However the system you describe is best practice anyhow, there's not much else you can do (aside from educate your users to take SSL warnings seriously if you can).
When you are not using SSL, all the communication can be easily intercepted - the only thing one need to do that is to launch packet sniffer (i.e. Wireshark).
SSL prevents that, all packets are encrypted so there is no way to know what you are sending out. Basically it is used for protecting passwords and private content from intercepting. You obviously do not want somebody else to read your private emails, right?
As for Google search, they simply did it to hide what people are asking for. This is because some governments are just too curious about it.
How SSL increase security? It does not by itself. What does is a combination of encryption (SSL key) and PKI (Public Key Infrastructure) - mainly Certificates. OK, the question was how. On one side it secures your communication channel (see above), on the other hand it ensures that you are talking to legitimate business - authenticates server. So the channel is secure and trusted.
There are quite a few SSL Certificates, as there are quite a few PKI Services. Basically different service needs different type of SSL Certificate. So there are Certificates for code signing, e-mail encryption and signing, the ones regarding i.e. server authentication, and so on.
@Vladimir is right that http://en.wikipedia.org/wiki/Forward_secrecy is desirable, but has the details wrong. The server chose this ciphersuite from among those offered by the browser. "encrypted with RC4_128 with SHA1 for message authentication" does use RC4 128-bit encryption and HMAC-SHA-1 integrity check. (Ciphersuite names in SSL/TLS until recently say SHA but they mean SHA-1 and actually HMAC-SHA-1.) "ECDHE_ECDSA as the key-exchange mechanism" does not apply to individual messages, it is part (most) of the handshake that occurs once at the beginning of the session: ECDHE uses the Elliptic Curve variant of Diffie-Hellman in Ephemeral mode (plus some additional steps not important here) to create the session keys used for encryption and HMAC; and the ECDHE key exchange (only) is signed by the Elliptic Curve variant of Digital Signature Algorithm. (You can never encrypt anything directly with DH or ECDH, they only do key or other small secret agreement.)
Is it safe for the user, or is it safe for you? Assume a man-in-the-middle attack. The attacker manages to capture the user's traffic, pretends to be you to the user, and pretends to be the user to you. That kind of attack would usually fail, because the certificate given to the user would not be right. For example, the attacker gives the user a self-signed certificate for your website. However, if the user acts stupidly, they may accept that self-signed certificate. So now the attacker can read and modify all the traffic between the user and you, and as far as I know there is no way for you to detect this.
So if the snooping and modification of traffic hurts the user, that's really their own fault and their own problem. And you can't prevent it completely anyway, because the MITM can cut you out completely and just talk to the user pretending to be you. But if snooping and modification of traffic hurts you, then you must trust the user not to be stupid, or better authenticate the user as well (the user would need a certificate, and you can check that in a way that the MITM can't fake).
Short answer is no.
Longer answer: a collection of the answers above plus:
If we solve the authentication, hence man-in-the-middle, that with traditional SSL connection someone listening to the traffic could still decrypt it later if they obtained a server secret key (think of NSA and National Security Letters).
There is a option in TLS protocol to use Diffie-Hellman protocol to assure link confidentially.
See the following picture when I am accessing gmail.com using Chrome. 
Look at text RC4_128 with SHA1 for message authentication ECDHE_ECDSA. This reads:
In other words, even if someone has private key of the SSL server, the messages have been encrypted with temporary keys that are discarded from memory soon after use. Good luck NSA!
I Think people here does not understand the question:
If you have a unsafe line, and you make a successful SSH/SSL Connection over this line, he now ask if its safe to make the assumption that the line is "secure" and that unencrypted data can be passed ALONGSIDE with the encrypted Connection (eg, in plain sight, not inside the encrypted SSL/SSH Connection).
I would say no. In this case, there could be a passive eavesdropper that simply ignores encrypted data and saves unencrypted data.
BUT you can be sure theres no Active eavesdropper (MITM), which means you can safely establish a unauthenticated SSL/SSH Connection with the same source/destination as the authenticated line. This provided theres no selective eavesdropper that MITM certain connectors, BUT however, the eavesdropper cannot know if you going to authenticate the Connection or not, so he cannot know which Connection to MITM to evade detection. The MITMer would, if he MITM, MITM all Connections and hope people click through all authentication dialogs simply.
Thus: If you connect authenticated to a SSL service from lets say 123.123.123.123 to 24.24.24.24, you can also safely connect a SSH client from 123.123.123.123 to 24.24.24.24 without mutually authenticating the SSH fingerprint, provided you can trust everything behind the other side's NAT router or firewall.
But even if thats safe generally meant, there IS a small risk that a eavesdropper simply random MITM Connections and hope for not being detected, so since you already have a authenticated Connection to the target IP, why not use that authenticated Connection to mutually verify the SSH fingerprint? Its simple as posting the correct SSH fingerprint on a SSL secured website!
Even the most modern versions of HTTPS using TLS can easily be intercepted by a MitM (e.g. a Juniper device configured for the purpose) if the client trusts the CA. In that particular case, it's not secure.
