Does an established HTTPS connection mean a line is really secure?

It's important to understand what SSL does and does not do, especially since this is a very common source of misunderstanding.

• It encrypts the channel
• It applies integrity checking
• It provides authentication

So, the quick answer should be: "yes, it is secure enough to transmit sensitive data". However, things are not that simple.

• The newest versions of SSL - version 3, or better yet: TLS, even TLS 1.2, are definitely better than previous versions. E.g. SSL 2 was relatively easy to MITM (Man in the middle). So, first it depends on protocol version.
• Both the channel encryption and the integrity checking are configurable in the protocol, i.e. you can choose which algorithms to use (cipher suite). Obviously, if you're using RSA1024/SHA512 you're much better off... However, SSL even support a mode of NULL encryption - i.e. no encryption at all, just wrapping the requests up to tunnel over SSL protocol. I.e., no protection. (This is configurable both at the client and the server, the selected cipher suite is the first matching set according to the configured order).
• Authentication in SSL has two modes: server-authentication only, and mutual authentication (client certificates). In both cases, the security ensured by the cryptographic certificates is definitely strong enough, however the validity of the actual authentication is only as good as your validity checks: Do you even bother checking the certificate? Do you ensure its validity? Trust chain? Who issued it? Etc.
• This last point re authentication is a lot easier in web applications, wherein the client can easily view the servers certificate, the lock icon is easily viewable, etc. With Web Services, you usually need to be more explicit in checking its validity (depending on your choice of platform). Note that this same point has tripped up so many mobile apps - even if the app developer remembered to use only TLS between the phone and the server, if the app doesn't explicitly verify the certificates then the TLS is broken.
• While there are some mostly theoretical attacks on the cryptography of SSL, from my PoV its still plenty strong enough for almost all purposes, and will be for a long time.
• What is actually done with the data at the other end? E.g. if its super-sensitive, or even credit card data, you dont want that in the browsers cache, or history, etc.
• Cookies (and thus authentication) can be shared between a secure, SSL channel, and a non-secure HTTP channel - unless explicitly marked with the "secure" attribute.

So, shorter answer? Yes, SSL can be secure enough, but (as with most things) it depends how you use it. :)

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.