ch14: Secure HTTP
Last updated
Last updated
We need a technology for HTTP security that provides:
Server authentication (clients know they're talking to the real server, not a phony)
Client authentication (servers know they're talking to the real user, not a phony)
Integrity (clients and servers are safe from their data being changed)
Encryption (clients and servers talk privately without fear of eavesdropping)
Efficiency (an algorithm fast enough for inexpensive clients and servers to use)
Ubiquity (protocols are supported by virtually all clients and servers)
Administrative scalability (instant secure communication for anyone, anywhere)
Adaptability (supports the best known security methods of the day)
Social viability (meets the cultural and political needs of the society)
The server certificate is an X.509 v3derived certificate.
The steps are:
The browser checks the certificate's start and end dates to ensure the certificate is still valid.
Every certificate is signed by some certificate authority (CA).
Browsers ship with a list of signing authorities that are trusted.
If a browser receives a certificate signed by some unknown authority, the browser usually displays a warning.
The browser check the certificate's integrity by applying the signing authority's public key to the signature and comparing it to the checksum.
To prevent a server from copying someone else's certificate or intercepting their traffic, most browsers try to verify that the domain name in the certificate matches the domain name of the server they takled to.
Once the client starts encrypting the data to the server, using the server's public key, the proxy no longer has the ability to read the HTTP header. And it won't know where to forward the request.
Use HTTPS tunneling protocol.
The client first tells the proxy the secure host and port to which it wants to connect.
And the client can transfer SSL data.
