Cryptography Reference
In-Depth Information
man-in-the-middle attack. HTTPS can, of course, be extended to work correctly
behind a proxy. This topic is revisited in Chapter 10.
Otherwise, this is it. After the
tls_connect
,
tls_send
,
tls_recv
, and
tls_shutdown
routines are complete, this client is HTTPS-compliant. If you are inclined to extend
display_result
to parse the HTML response and build a renderable web page,
you can do so without giving a single thought to whether or not the connection
is secure. If you add support for POST, HEAD, PUT, DELETE, and so on into the
client-side implementation, you do so just as if the connection was plaintext; just
be sure to call
tls_send
instead of
send
. Of course, you should probably extend
this to actually pay attention to the protocol and perform a TLS connection only if
the user requested “https” instead of “http.” I'll leave that as an exercise for you
if you're interested.
Understanding the TLS Handshake Procedure
Most of the complexity is in the handshake; after the handshake has been
completed, sending and receiving is just a matter of encrypting/decrypting,
MAC'ing/verifying data before/after it's received. At a high-level, the handshake
procedure is as shown in Figure 6-1.
client
server
client hello
server hello
certificate
hello done
key exchange
change cipher spec
finished
change cipher spec
finished
Figure 6-1:
TLS handshake
Search WWH ::
Custom Search