SSL : Java Glossary

Introduction

SSL (Secure Sockets Layer) is the protocol used communicate over an encrypted connection and to authenticate none, one or both of the participants. There are two versions SSL version 2 (SSL v2) and SSL version 3 ( SSL v3). SSL v3 is more flexible and safer than SSL v2. It works by the website sending its X.509 v3 certificate containing its public key to your browser. That allows session keys to be exchanged to encrypt the following traffic.

SSL has almost completely been replaced with TLS (Transport Layer Security), though nearly everyone improperly refers to TLS as SSL.

If a TLS 1.2 and TLS 1.0 socket get together, normally would start a new TLS 1.0 connection.

Levels

SSL is not used anymore. They foolishly renamed it to TLS to cause confusion. Nearly everyone still uses the old name.

The JSSE (Java Secure Socket Extension) implementation shipped with the JDK (Java Development Kit) still supports SSL 3.0 (the most primitive). Java uses TLS 1.2 by default. 1.2 is backward compatible with 1.0 and 1.1. 1.3 is still is a draft.

Subprotoctols

Disabling Older Protocols

You might want to disable older protocols. You can do it with a system property like this:

You can do it in Java source by setting a system property like this:

Should You Flip to SSL?

Google has been successfully pushing nearly everyone to use SSL, whether they need it or not. Is that a good idea?

Advantages

• It lets you send credit card information to a server without fear of anyone snooping. This is not quite true. Government agencies will still be able to snoop as will employees of the server company and anyone who manages to hack the server.
• It lets you be sure the party to whom you are disclosing sensitive information is indeed whom they claim to be.
• It drowns the spy agencies and industrial spies in encrypted data. They waste resources cracking the code to find out it is only something as mundane as a shopping list.

Disadvantages

• If your clients have any trouble with SSL, they just go away. They have no way of contacting you to get the problem resolved. This includes spidering search engines.
• It suppresses caching. This means every request has to be custom-generated by the server.
• It suppresses compression, other than that done by the server.
• If you don’t need the security, it wastes bandwidth on a massive scale.
• Servers must pay an exorbitant fee each year for an SSL certificate.
• Web masters frequently forget that their certificates expire each year and must be renewed. This means Chrome will block their sites for a week or two each year while they buy a new certificate.
• It slows things down. Every message must be encrypted and decrypted with intensive CPU (Central Processing Unit) processing. There is no point in doing this for information that is not confidential.
• It requires extra processing power at both the server and client. This mean more expensive computers and consuming more electricity. On a global level this is a blow at the environment.
• SSL/TLS/key exchange is a very complicated protocol with many variants, versions and configuring parameters. There is a good chance any random client will not be able to communicate with any random server, especially if one of the ends is Java. Tracking down and fixing these problem takes a significant amount of labour. Much of the time, you cannot solve the problem and have to live with a connection not working.
• It inhibits protocol sniffing with tools like Wireshark. This make the usual tools for debugging ineffective. It makes it very difficult to arrange screenscraping.
• I spend about 30 minutes a day on average tracking down why https: links from my site have stopped working. Sometimes I can get them going again by turning on SNI (Server Name Indication). Sometimes I can get them working by importing some root certificates. Sometimes I send emails explaining to webmasters how they screwed up configuring their SSL certificates (usually leaving off an alternate domain). Often, I just have to give up. This is a PITA (Pain In The Ass).

Under The Hood

The magic of SSL is that there need be no a-priori secret password or private key shared between the two, though there optionally could be a login process. The two ends can set up a secure channel between themselves, even if they have never met before, even if there is someone snooping on the whole process! SSL uses ponderous public/private key techniques to exchange high speed symmetric keys for encrypting the bulk of the traffic.

The nice feature about SSL is that it can use different lengths of key for different purposes. This allows it to get around the foolish US laws that restrict long keys for privacy but allow them for identification and data integrity checking. SSL will still work even if the client does not have a certificate. SSL encryption software for export is limited by a U.S. law to 512-bit public keys and 40-bit private keys, even though the knowledge to build such software is freely available globally. All such laws do is give foreign companies such a BouncyCastle access to markets the US government locks American corporations out of.

If you create an Applet and run it from within a browser, you can successfully open a url connection with https://www.charlie.com/�. The browser takes care all the SSL stuff for you. Java handles all the details of SSL for you in an Applet so that they are almost identical to ordinary HTTP (Hypertext Transfer Protocol) transactions.

SSL Software Vendors

• OpenSSL. This is the most widely used. It is free. It made the news when it was hit by some extremely nasty malware that almost shut down the Internet for a week.
• SSLithium which is licensed for non-commercial use only
• iSaSiLk which is commercially available and was the basis for the international offering from Entrust
• JForge (which uses the www.aba.net.au JCE (Java Cryptography Extension) )
• TLS (SSL3.1) implementation called pureTLS
• Phaos makes SSLava.
• With Java SSL is built-in via JSSE. See the javax.net.ssl class.

Tips

• Check the Windows 10 updates, and apply them all. Windows does not apply them automatically. SSL behaves much better under Java after all the updates are applied.
• The common name in SQL (Standard Query Language) certificate must be a fully-qualified domain name, or Java won’t recognise the match. If you have a website with many domains, you need a wildcard certificate to cover the related domains, or a separate certificate for each domain.
• 
  
• Beware there are three SSL packages: javax.net.ssl, com.sun.net.ssl, com.sun.net.ssl.internal.www.protocol.https. Normally, you should not be messing with com.sun packages.
• The software to handle SSL in Java is called JSSE, JSSE and is not considered part of JCE.
• SSL chews up huge amounts of the server�s CPU time. One solution is an SSL hardware box that acts as a proxy server. This is not such much of a problem today with multi-core very fast CPUs (Central Processing Units).
• To connect as a client in HTTPS (Hypertext Transfer Protocol over SSL (Secure Socket Layer)) , you connect just like a regular HTTP connection. However, you have to give the SSL library access to your collection of certificate authority certificates so your client can validate server certificates:
• java -Djavax.net.ssl.trustStore=myCertStore.jks -Djavax.net.ssl.trustStorePassword=sesame -jar MyClient.jar
• IETF (Internet Engineering Task Force) manages SSL and has renamed it TLS TLS. People still usually refer to it as SSL. Properly TLS refers to the newer versions of the protocol and SSL to the older.
• Other than the initial DNS (Domain Name Service) lookup, everything with https: is encrypted, including the URL (Uniform Resource Locator) you are requesting. That is why Wireshark cannot snoop even on your own transactions.

Types of SSL certificate

• A wildcard SSL certificate will cover multiple subdomains specified by a wildcard. A standard SSL cert covers just one domain or a list of explicit domains in the Subject Alternative Name field.
• A standard certificate just verifies that you own the domain.
• An organisation validation verifies that a given company owns the domain as well.
• An extended validation requires passing a mini-audit that you are a trustworthy company and take reasonable security precautions.

The more research the certificate authority does to ensure the authenticity of the server, the more expensive the certificate. The user wants to be sure they are sending data to whom they think they are, not an imposter.

What Certificate is a Site Using?

You can find out what SSL certificate a site is using with Firefox or Opera by clicking the icon to the left of the URL, (with IE and Safari click the lock icon to the right) to give you certificate details. Chrome no longer lets you view the certificate. You need a root certificate in the chain in your store for that certificate to work.

You can also get more detailed information from the Comodo certificate analyser

Components

The technical details of TLS/SSL are quite complicated, but here are the pieces: The server requires a certificate, a digitally signed id that attests that the server his in his possession secret/private key, 512 to 2048 bits long corresponding to a public key available for perusal. The user does not need a certificate. The server and user start the exchange with a cumbersome Diffie-Hellman protocol that does not require the two to share a secret password/key beforehand. Sometimes a faster X.509 certificate-based elliptical RSA scheme is used instead. Then they securely exchange 128 bit random numbers to use as keys for the bulk of the transmission, using a faster, simpler AES protocol.

RFCs (Request For Comments)

• RFC 3526: Diffie Hellman
• RFC 7296: IKE (Internet Key Exchange)
• RFC 5746: TLS renegotiation

Key Sizes

Diffie-Hellman (the protocol used to start a session) can work with 512, 768, 1024, 1536, 2048, 3072, 4096, 6144 or 8192 bit keys. There is a magic prime number associated with each size of key that is used in the cryptography. There can be problems if a server, for example, is using 2048-bit keys, but the client only supports 1536-bit keys. How big the key size in Java can be depends on:

• the JDK version
• Whether you are using Diffie-Hellman or X.509 as the trigger protocol.
• Whether you have unlimited strength encryption (non-exportable) installed.
• how you specify the jdk.tls.ephemeralDHKeySize system property. You cannot set it bigger than 2048 even though many sites use a bigger key. You can set it only to 1024 or 2048.

Oracle is dropping support for 512 and 768-bit keys since they are no longer secure.

Java SSL Support

Java leaves something to be desired in SSL support. Part of the problem can be missing root certificates in cacerts. That can be fixed by tracking down the root certificates and installing them.

Anomalies

There are a number of URLs (Uniform Resource Locators) that browsers handle without trouble that Java fails on. Here is a list of some of them. Oddly when you install the anniversary Windows 10 update, they will start working

To experiment with anomalies, just do a URLConnection. You don’t have to read any bytes, just connect. If you want some software to experiment with Java’s SSL try the TestConnection program below:

The most common problem is you failed to import some root certificate into all your cacerts files.

The next most common problem is you failed to match Java’s SNI support to what the site supports.

How SSL Works

SSL/TSL is a two-stage protocol. In the first stage, the two ends decide on a temporary common session key to use for just this session. In the second stage, the data are efficiently encrypted and sent with that symmetric key.

The second thing to understand is SS is a Chinese menu protocol with dozens of variants. To start, the two ends must negotiate which variants they will use. There is no guarantee they both support a common set of features.

1. Client Hello

   The client sends server information about which SSL variants it supports.

2. Server Hello

   The server sends client information about which SSL variants it supports. The server sends client its certificate public key. The server needs a certificate, but the client does not.

3. Authentication and Pre-Master Secret

   The client authenticates the server certificate. It can do this without contacting the certificate company because it has the corresponding root certificates on file. The client prepares a random pre-master session key. The client encrypts the key with the server’s public key and sends it to the server.

4. Decryption and Master Secret

   The server uses its private key to decrypt the pre-master secret. Both server and client perform the math to generate the master secret.

5. Generate Session Keys

   Both the client and the server use the master secret to generate the session keys. (I don’t understand why they don’t just generate the session key directly.)

6. Encryption with Session Key

   Both client and server exchange messages to notify that all future messages they send will be encrypted with the session key.

Books

Book referral for SSL and Tls: Theory and Practice, Second Edition

	recommend book⇒SSL and Tls: Theory and Practice, Second Edition
	by	Rolf Oppliger Ph.D.	978-1-60807-998-8	hardcover
	birth	1965-11-02 age:52
	publisher	Artech House Publishers
	published	2016-03-31
The author is a computer science professor at the University of Zurich in Switzerland. Curriculum vitae.
Online bookstores carrying SSL and Tls: Theory and Practice, Second Edition abe books anz abe books.ca abe books.de amazon.ca amazon.de Chapters Indigo amazon.es Chapters Indigo eBooks iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Nook at Barnes & Noble amazon.it Kobo junglee.com Google play abe books.co.uk O’Reilly Safari amazon.co.uk Powells other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

Book referral for Implementing SSL / TLS Using Cryptography and PKI

	recommend book⇒Implementing SSL / TLS Using Cryptography and PKI
	by	Joshua Davies	978-0-470-92041-1	paperback
	birth	1974 age:43	978-1-118-03877-2	eBook
	publisher	Wiley	B004IK9TVO	kindle
	published	2011-01-11
Practical, comprehensive book on how to implement SSL / TLS. Covers only TLS 1.0.
Online bookstores carrying Implementing SSL / TLS Using Cryptography and PKI abe books anz abe books.ca abe books.de amazon.ca amazon.de Chapters Indigo amazon.es Chapters Indigo eBooks iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Nook at Barnes & Noble amazon.it Kobo junglee.com Google play abe books.co.uk O’Reilly Safari amazon.co.uk Powells other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

Learning More