Where does SSL encryption take place?
The SSL protocol is implemented as a transparent wrapper around the HTTP protocol. In terms of the OSI model, it's a bit of a grey area. It is usually implemented in the application layer, but strictly speaking is in the session layer.
Think of it like this:
- Physical layer (network cable / wifi)
- Data link layer (ethernet)
- Network layer (IPv4)
- Transport layer (TCP)
- Session layer (SSL)
- Presentation layer (none in this case)
- Application layer (HTTP)
Notice that SSL sits between HTTP and TCP.
If you want to see it in action, grab Wireshark and browse a site via HTTP, then another via HTTPS. You'll see that you can read the requests and responses on the HTTP version as plain text, but not the HTTPS ones. You'll also be able to see the layers that the packet is split into, from the data link layer upwards.
Update: It has been pointed out (see comments) that the OSI model is an over-generalisation and does not fit very well here. This is true. However, the use of this model is to demonstrate that SSL sits "somewhere" in between TCP and HTTP. It is not strictly accurate, and is a vague abstraction of reality.
With HTTPS, encryption occurs between the Web browser and the Web server. Firebug runs on the browser itself, so it sees the cleartext data; encryption takes place when exiting the browser.
Use a network monitor tool (such as Microsoft Network Monitor or Wireshark) to observe the encrypted traffic. Use a Man-in-the-Middle attack product like Fiddler to get a taste of what an attacker can do (namely: intercepting the connection and recovering the data is feasible IF the user can be persuaded to "ignore the friggin' browser warnings" about untrusted certificates -- so don't ignore the warnings !).
HTTPS is HTTP over TLS (or over SSL, which is the name of previous versions of TLS).
SSL/TLS, when configured properly, provides privacy and data integrity between two communicating applications (see TLS specification), over a reliable transport, typically TCP.
Although TCP sockets are not mentioned in the TLS specification, SSL and TLS were designed with the objective of providing a model that could be used almost like plain TCP sockets by application programmers. Besides a few edge cases (for example, for closing sockets or if you want your application you application to be aware of re-negotiations), this is indeed mostly the case. SSL/TLS stacks often provide wrappers that make the SSL/TLS sockets be programmable in the same way as plain TCP sockets (once configured); for example Java's SSLSocket extends Socket.
Most applications rely on existing libraries to use SSL/TLS (for example JSSE in Java, SChannel, OpenSSL, Mozilla's NSS library, OSX's CFNetwork, ...). With little modifications to the plain TCP code (usually, everything around certificate and trust management, and encryption/cipher suites settings if required), SSL/TCP sockets (or streams, depending on the type of API) are used to exchange plain text as far as the application is concerned. It's the underlying library that tends to do the encryption work, transparently.
When you look at the traffic within the browser's developer's tools, it's what's exchanged on top of those libraries that you see. To see the encrypted traffic, you'd need to look at the actual traffic (e.g. using Wireshark).