Using HTTPS in Java
HTTPS is implemented as a protocol just like HTTP. Whereas an HTTP URL starts with “http”, an HTTPS protocol starts with “https”. For example, the following URL specifies a secure page on the HTTP Recipe Site:
https://www.httprecipes.com/1/5/https.php
It is important to understand that a URL that starts with “https” is not just a secure version of the same URL beginning with an “http”. Consider the following URL:
http://www.httprecipes.com/1/5/https.php
The two URLs you see in this section are exactly the same, except that one is HTTP and the other HTTPS. You might think that entering the second URL would simply take you to an unencrypted version of the https.php page. It does not. If you enter the second URL into a web browser, you will get a page not found, or the 404, error.
This is because the file https.php does not exist on the “HTTP Recipes” site’s unencrypted server. This is the important distinction. There are two web servers running at . There is an unencrypted HTTP server running at port 80. There is also an encrypted HTTPS server running at port 443. These two servers do not share the same set of HTML files. In the case of the HTTP Recipes site, Chapter 5 is hosted on the HTTPS server, and the rest of the chapters on the HTTP server.
Hypertext Transfer Protocol Secure (HTTPS) uses sockets just like HTTP. However, it uses a special sort of socket called a secure socket. Secure sockets are implemented using the Secure Socket Layer (SSL). SSL, which is supported by Java, provides two very important security mechanisms, which are listed here.
- Encrypted packets
- Server verification
Web servers commonly use both of these mechanisms. These two mechanisms will be discussed in the next two sections.
Understanding Encrypted Packets
The aspect that most users associate with HTTPS, is data encryption. When you use an HTTPS site, you normally see a small “lock symbol” near the bottom of your browser. Once you see the lock, you know that your data is being encrypted, and you are using a secure site.
Data encryption is very important. When you enter a credit card number into a web site, you want to be sure that only that web site gains access to your credit card number. Because TCP/IP traffic can travel through a number of different hosts before it finally reaches your intended web server, you do not want a malicious user intercepting your credit card number somewhere between you and the web server.
By encrypting the packets being exchanged between you and the web server, the problem of your packets getting intercepted is decreased. If someone does intercept your packet, it will be encrypted.
Understanding Server Verification
Encryption is not the only benefit provided by HTTPS. Server verification is another important benefit. Consider what happens when you access the following URL:
https://www.httprecipes.com/1/5/https.php
The web browser takes apart the URL and finds the hostname. In this case, the host name is www.httprecipes.com. This is a domain name, which the web browser then looks up in a Domain Name System (DNS) server. As of the writing of this book, the IP address for www.httprecipes.com is 216.69.170.193. But how do you know that the IP address 216.69.170.193 is really the HTTP Recipes site? IP addresses sometimes change when the web master switches hosting companies, or for other reasons. Someone could have hijacked the www.httprecipes.com DNS entry and pointed it to a malicious web server running on a different IP address.
HTTPS solves this problem. Part of the SSL protocol, upon which HTTPS is based, verifies that the IP address returned by DNS is the actual address of the site. Every website that uses HTTPS must be issued a SSL certificate. Usually these certificates are issued by Verisign (http://www.verisign.com
). When a web server is granted a certificate, the company that issues the certificate verifies the IP address that the certificate is issued to matches the domain name.
When you access https://www.httprecipes.com
, your web browser looks up the returned IP address of 216.69.170.193 with the company that issued the HTTP Recipes site our SSL certificate. If these IP addresses do not match, then your browser will warn you.
Most certificate issuers provide “seals” that web masters can place on their web sites to show that their identity has been verified. Figure 5.1 shows the seal on the HTTP Recipes site:
Figure 5.1: HTTPS Verification Seal

You can click the site’s seal and be taken to the certificate issuer’s web site. This will display the certificate. The SSL certificate for HTTP Recipes can be seen in Figure 5.2.
Figure 5.2: The HTTP Recipes Certificate

Now that you understand what HTTPS is and how it is used, the next section will show you how to write Java programs that make use of HTTPS.
Using HTTPS in Java
Java provides methods that make it simple to connect to an HTTPS. The following code would open an HttpURLConnection to an HTTPS server:
try
{
URL u = new URL("https://www.httprecipes.com/1/5/https.php");
HttpURLConnection http = (HttpURLConnection)u.openConnection();
// Now do something with the connection.
}
catch(MalformedURLException e)
{
System.out.println("Invalid URL");
}
catch(IOException e)
{
System.out.println("Error connecting: " + e.getMessage() );
}Does something seem familiar about this code? It is exactly the same code used to access an HTTP URL that was introduced in Chapter 4 with the https URL instead. Java supports HTTPS transparently. Simply pass an “https” based URL to any of the code used in this book, and HTTPS will be supported.




