SSL and TLS are protocols that aim to provide privacy and data integrity between two parties (see RFC 2246), designed to run over a reliable communication protocol (typically TCP). Although the TLS specification doesn’t talk about sockets, the design of SSL/TLS was done so that applications could use them almost like traditional TCP sockets, for example SSLSocket in Java extends Socket (there are small differences in terms of usability, though).
HTTPS is HTTP over SSL/TLS, where the SSL/TLS connection is established first, and then normal HTTP data is exchanged over this SSL/TLS connection. Whether you use SSL or TLS for this depends on the configuration of your browser and of the server (there usually is an option to allow SSLv2, SSLv3 or TLS 1.x). The details of how HTTP and SSL/TLS form HTTPS are in RFC 2818.
Regarding the difference between SSL and TLS, you may be interested in these two answers I wrote for these similar questions on StackOverflow and ServerFault:
You could consider TLSv1.0 as SSLv3.1 (in fact that’s what happens within the records exchanged). It’s just easier to compare the TLSv1.0 with TLSv1.1 and TLSv1.2 because they’ve all been edited within IETF and follow more or less the same structure. SSLv3 being edited by a different institution (Netscape), it makes it a bit more difficult so spot the differences.
Here are a few differences, but I doubt I can list them all:
- In the ClientHello message (first message sent by the client, to initiate the handshake), the version is {3,0} for SSLv3, {3,1} for TLSv1.0 and {3,2} for TLSv1.1.
- The ClientKeyExchange differs.
- The MAC/HMAC differs (TLS uses HMAC whereas SSL uses an earlier version of HMAC).
- The key derivation differs.
- The client can send application data can be sent straight after sending the SSL/TLS Finished message in SSLv3. In TLSv1, it must wait for the server’s Finished message.
- The list of cipher suites differ (and some of them have been renamed from SSL_* to TLS_*, keeping the same id number).
- There are also differences regarding the new re-negotiation extension.
Generally, the higher the version or SSL/TLS, the more secure it is, provided you choose your cipher suites properly too (higher versions of TLS also offer using cipher suites that are considered better). (SSLv2 is considered insecure.) In addition, SSL doesn’t fall under the IETF scope. For example, the TLS renegotiation fix had to be retrofitted for SSLv3 (although SSL/TLS stacks had to be updated anyway).
You may also be interested in this answer:
Note that some people oppose SSL and TLS as being the difference between “SSL/TLS upon connection” and “upgrade to TLS” (after some conversation using the application protocol). Despite some of these answers being relatively highly upvoted, this is incorrect. This mistake is propagated by the fact that certain applications, like Microsoft Outlook, offer two configuration options called “SSL” and “TLS” for SMTP/IMAP configuration when they really mean “SSL/TLS upon connection” and “upgrade to TLS”. (The same goes for the JavaMail library, I think.)
The RFCs that talk about STARTTLS were written when TLS was already an official RFC, that’s why they only talk about upgrading the connection to TLS. In practice, if you tweak the configuration of your mail client to force it to use SSLv3 instead of TLS (not something I would generally recommend), it’s still likely to be able to upgrade to SSL/TLS using STARTTLS with an SSLv3 connection, simply because it’s more about the mode of operation than the version of SSL/TLS and/or the cipher suites.
There is also a variant of HTTP where the upgrade to SSL/TLS is done within the HTTP protocol (similar to STARTTLS in LDAP/SMTP). This is described in RFC 2817. As far as I know, this is almost never used (and it’s not what’s used by https:// in browsers). The main relevant part of this RFC is the section about CONNECT for HTTP proxy servers (this is used by HTTP proxy servers to relay HTTPS connections).