Secure HTTP
Making HTTP Safe
We need a technology for HTTP security that provides:
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)
HTTPS
Digital Cryptography
The Art and Science of Secret Coding
Ciphers
Cipher Machines
Keyed Ciphers
Digital Ciphers
Symmetric-Key Cryptography
Many digital cipher algorithms are called symmetric-key ciphers, because they use the same key value for encoding as they do for decoding (e = d).
Some popular symmetric-key cipher algorithms are DES, Triple-DES, RC2, and RC4.
Key Length and Enumeration Attacks
Establishing Shared Keys
Public-Key Cryptography
RSA
Hybrid Cryptosystems and Session Keys
Digital Signatures
Signatures Are Cryptographic Checksums
Digital signatures are special cryptographic checksums attached to a message. They have two benefits:
The Art and Science of Secret Coding
Ciphers
Cipher Machines
Keyed Ciphers
Digital Ciphers
Symmetric-Key Cryptography
Many digital cipher algorithms are called symmetric-key ciphers, because they use the same key value for encoding as they do for decoding (e = d).
Key Length and Enumeration Attacks
Establishing Shared Keys
Public-Key Cryptography
RSA
Hybrid Cryptosystems and Session Keys
Digital Signatures
Signatures Are Cryptographic Checksums
Digital signatures are special cryptographic checksums attached to a message. They have two benefits:
- Signatures prove the author wrote the message. Because only the author has the author’s top-secret private key,* only the author can compute these checksums. The checksum acts as a personal “signature” from the author.
- Signatures prevent message tampering. If a malicious assailant modified the message in-flight, the checksum would no longer match. And because the checksum involves the author’s secret, private key, the intruder will not be able to fabricate a correct checksum for the tampered-with message.
Digital signatures often are generated using asymmetric, public-key technology.
Digital Certificates
In this section, we talk about digital certificates, the “ID cards” of the Internet. Digital certificates (often called “certs,” like the breath mints) contain information about a user or firm that has been vouched for by a trusted organization.
The Guts of a Certificate
Basic digital certificates commonly contain basic things common to printed IDs, such as:
Digital Certificates
In this section, we talk about digital certificates, the “ID cards” of the Internet. Digital certificates (often called “certs,” like the breath mints) contain information about a user or firm that has been vouched for by a trusted organization.
The Guts of a Certificate
Basic digital certificates commonly contain basic things common to printed IDs, such as:
- Subject’s name (person, server, organization, etc.)
- Expiration date
- Certificate issuer (who is vouching for the certificate)
- Digital signature from the certificate issuer
X.509 v3 Certificates
The good news is that most certificates in use today store their information in a standard form, called X.509 v3. X.509 v3 certificates provide a standard way of structuring certificate information into parseable fields. Different kinds of certificates have different field values, but most follow the X.509 v3 structure.
Using Certificates to Authenticate Servers
The server certificate contains many fields, including:
If the signing authority is unknown, the browser isn’t sure if it should trust the signing authority and usually displays a dialog box for the user to read and see if he trusts the signer. The signer might be the local IT department, or a software vendor.
HTTPS: The Details
HTTPS is the most popular secure version of HTTP. It is widely implemented and available in all major commercial browsers and servers. HTTPS combines the HTTP protocol with a powerful set of symmetric, asymmetric, and certificate-based cryptographic techniques, making HTTPS very secure but also very flexible and easy to administer across the anarchy of the decentralized, global Internet.
HTTPS Overview
HTTPS Schemes
Secure Transport Setup
SSL Handshake
Before you can send encrypted HTTP messages, the client and server need to do an SSL handshake, where they:
Server Certificates
Site Certificate Validation
The steps are:
Virtual Hosting and Certificates
It’s sometimes tricky to deal with secure traffic on sites that are virtually hosted (multiple hostnames on a single server). Some popular web server programs support only a single certificate. If a user arrives for a virtual hostname that does not strictly match the certificate name, a warning box is displayed.
A Real HTTPS Client
OpenSSL -OpenSSL is the most popular open source implementation of SSL and TLS.
A Simple HTTPS Client - Refer to http://www.openssl.org for more information about the OpenSSL libraries.
Executing Our Simple OpenSSL Client
% https_client clients1.online.msdw.com
(1) SSL context initialized
(2) 'clients1.online.msdw.com' has IP address '63.151.15.11'
(3) TCP connection open to host 'clients1.online.msdw.com', port 443
(4) SSL endpoint created & handshake completed
(5) SSL connected with cipher: DES-CBC3-MD5
(6) server's certificate was received:
subject: /C=US/ST=Utah/L=Salt Lake City/O=Morgan Stanley/OU=Online/CN=
clients1.online.msdw.com
issuer: /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
(7) sent HTTP request over encrypted channel:
GET / HTTP/1.0
Host: clients1.online.msdw.com:443
Connection: close
(8) got back 615 bytes of HTTP response:
HTTP/1.1 302 Found
Date: Sat, 09 Mar 2002 09:43:42 GMT
Server: Stronghold/3.0 Apache/1.3.14 RedHat/3013c (Unix) mod_ssl/2.7.1 OpenSSL/0.9.6
Location: https://clients.online.msdw.com/cgi-bin/ICenter/home
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF="https://clients.online.msdw.com/cgi-bin/ICenter/
home">here</A>.<P>
<HR>
<ADDRESS>Stronghold/3.0Apache/1.3.14 RedHat/3013c Server at clients1.online.msdw.com
Port 443</ADDRESS>
</BODY></HTML>
(9) all done, cleaned up and closed connection
Tunneling Secure Traffic Through Proxies
HTTP is used to send the plaintext endpoint information, using a new extension method called CONNECT. The CONNECT method tells the proxy to open a connection to the desired host and port number and, when that’s done, to tunnel data directly between the client and server. The CONNECT method is a one-line text command that provides the hostname and port of the secure origin server, separated by a colon. The host:port is followed by a space and an HTTP version string followed by a CRLF. After that there is a series of zero or more HTTP request header lines, followed by an empty line. After the empty line, if the handshake to establish the connection was successful, SSL data transfer can begin. Here is an example:
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/1.1N
<raw SSL-encrypted data would follow here...>
After the empty line in the request, the client will wait for a response from the proxy. The proxy will evaluate the request and make sure that it is valid and that the user is authorized to request such a connection. If everything is in order, the proxy will make a connection to the destination server and, if successful, send a 200 Connection Established response to the client.
HTTP/1.0 200 Connection established
Proxy-agent: Netscape-Proxy/1.1
The good news is that most certificates in use today store their information in a standard form, called X.509 v3. X.509 v3 certificates provide a standard way of structuring certificate information into parseable fields. Different kinds of certificates have different field values, but most follow the X.509 v3 structure.
Using Certificates to Authenticate Servers
The server certificate contains many fields, including:
- Name and hostname of the web site
- Public key of the web site
- Name of the signing authority
- Signature from the signing authority
HTTPS: The Details
HTTPS is the most popular secure version of HTTP. It is widely implemented and available in all major commercial browsers and servers. HTTPS combines the HTTP protocol with a powerful set of symmetric, asymmetric, and certificate-based cryptographic techniques, making HTTPS very secure but also very flexible and easy to administer across the anarchy of the decentralized, global Internet.
HTTPS Overview
HTTPS Schemes
Secure Transport Setup
SSL Handshake
Before you can send encrypted HTTP messages, the client and server need to do an SSL handshake, where they:
- Exchange protocol version numbers
- Select a cipher that each side knows
- Authenticate the identity of each side
- Generate temporary session keys to encrypt the channel
Site Certificate Validation
The steps are:
- Date check
- Signer trust check
- Signature check
- Site identity check
Virtual Hosting and Certificates
It’s sometimes tricky to deal with secure traffic on sites that are virtually hosted (multiple hostnames on a single server). Some popular web server programs support only a single certificate. If a user arrives for a virtual hostname that does not strictly match the certificate name, a warning box is displayed.
A Real HTTPS Client
OpenSSL -OpenSSL is the most popular open source implementation of SSL and TLS.
A Simple HTTPS Client - Refer to http://www.openssl.org for more information about the OpenSSL libraries.
Executing Our Simple OpenSSL Client
% https_client clients1.online.msdw.com
(1) SSL context initialized
(2) 'clients1.online.msdw.com' has IP address '63.151.15.11'
(3) TCP connection open to host 'clients1.online.msdw.com', port 443
(4) SSL endpoint created & handshake completed
(5) SSL connected with cipher: DES-CBC3-MD5
(6) server's certificate was received:
subject: /C=US/ST=Utah/L=Salt Lake City/O=Morgan Stanley/OU=Online/CN=
clients1.online.msdw.com
issuer: /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
(7) sent HTTP request over encrypted channel:
GET / HTTP/1.0
Host: clients1.online.msdw.com:443
Connection: close
(8) got back 615 bytes of HTTP response:
HTTP/1.1 302 Found
Date: Sat, 09 Mar 2002 09:43:42 GMT
Server: Stronghold/3.0 Apache/1.3.14 RedHat/3013c (Unix) mod_ssl/2.7.1 OpenSSL/0.9.6
Location: https://clients.online.msdw.com/cgi-bin/ICenter/home
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF="https://clients.online.msdw.com/cgi-bin/ICenter/
home">here</A>.<P>
<HR>
<ADDRESS>Stronghold/3.0Apache/1.3.14 RedHat/3013c Server at clients1.online.msdw.com
Port 443</ADDRESS>
</BODY></HTML>
(9) all done, cleaned up and closed connection
Tunneling Secure Traffic Through Proxies
HTTP is used to send the plaintext endpoint information, using a new extension method called CONNECT. The CONNECT method tells the proxy to open a connection to the desired host and port number and, when that’s done, to tunnel data directly between the client and server. The CONNECT method is a one-line text command that provides the hostname and port of the secure origin server, separated by a colon. The host:port is followed by a space and an HTTP version string followed by a CRLF. After that there is a series of zero or more HTTP request header lines, followed by an empty line. After the empty line, if the handshake to establish the connection was successful, SSL data transfer can begin. Here is an example:
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/1.1N
<raw SSL-encrypted data would follow here...>
After the empty line in the request, the client will wait for a response from the proxy. The proxy will evaluate the request and make sure that it is valid and that the user is authorized to request such a connection. If everything is in order, the proxy will make a connection to the destination server and, if successful, send a 200 Connection Established response to the client.
HTTP/1.0 200 Connection established
Proxy-agent: Netscape-Proxy/1.1
No comments:
Post a Comment