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. 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, when configured properly, provides privacy and data integrity between two communicating applications (see TLS specification), over a reliable transport, typically TCP.Īlthough 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. HTTPS is HTTP over TLS (or over SSL, which is the name of previous versions of TLS). It is not strictly accurate, and is a vague abstraction of reality. However, the use of this model is to demonstrate that SSL sits "somewhere" in between TCP and HTTP. Update: It has been pointed out (see comments) that the OSI model is an over-generalisation and does not fit very well here. You'll also be able to see the layers that the packet is split into, from the data link layer upwards.
You'll see that you can read the requests and responses on the HTTP version as plain text, but not the HTTPS ones. If you want to see it in action, grab Wireshark and browse a site via HTTP, then another via HTTPS. Notice that SSL sits between HTTP and TCP. It is usually implemented in the application layer, but strictly speaking is in the session layer. In terms of the OSI model, it's a bit of a grey area.
The SSL protocol is implemented as a transparent wrapper around the HTTP protocol.
0 kommentar(er)
