2. CIPHER SUITE
Each name has an algorithm divided into four parts: protocol, key exchange algorithm,
encryption algorithm, and checksum. For example, the name SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA means
Secure Sockets Layer Version 3; Diffie-Hellman method for key agreement; no authentication; Data Encryption Standard en‐cryption with 40-bit keys; Cipher Block Chaining, and the Secure Hash Algorithm checksum.

3. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
In english (more-or-less), these cipher suites implement Elliptic-curve Diffie-Hellman Ephemeral key exchange using the Elliptic-curve Digital Signature Algorithm, with AES-128/256 as the block cipher and SHA- 256/384 HMAC for the authentication hash.

4. Elliptic Curves
Elliptic Curve Cryptography provides much-increased security for a given key size over plain RSA or DSA.

5. Diffie-Hellman key exchange
Diffie-Hellman is a key exchange method. It allows two actors, each with a public and a private key, to arrive at a shared secret (through math) without either revealing their private key.

6. Ephemeral
With standard DH key exchange, a given communication with the same public and private key arrives at the same secret every time. So, if some entity happens to be storing all of your encrypted communications in a database somewhere, as soon as they are able to obtain the secret they can immediately decrypt all of those messages.
By contrast, communications using Ephemeral key exchange will generate a unique secret for each message, making it impossible to bulk-decrypt them.

7. DSA (DSS)
DSA is a signing algorithm. It’s been in use for quite a while, and is generally thought to be secure for sufficiently large key sizes (2048 and up)

8. AES-GCM
AES stands for “Advanced Encryption Standard,” and is more technically referred to as Rijndael. It is the winner of the 2001 NIST Advanced Encryption Standard contest, superceding the older DES
GCM (Galois/Counter Mode) refers to the mode of operation used by the encryption algorithm. 

9. SHA-256/384
SHA-256 and SHA-384 are one-way hash functions used for message verification. Both are members of the SHA-2 family (contrast with SHA-1). Where MD5 is more-or-less broken, and SHA-1 has had theoretical vulnerabilities published, SHA-2 is as-yet untouched.

10. Java Secure Socket Extension
The Java Secure Socket Extension is divided into four packages:
javax.net.ssl
The abstract classes that define Java’s API for secure network communication
javax.net
The abstract socket factory classes used instead of constructors to create secure sockets.
java.security.cert
The classes for handling the public-key certificates needed for SSL.
com.sun.net.ssl
The concrete classes that implement the encryption algorithms and protocols in Sun’s reference implementation of the JSSE. Technically, these are not part of the JSSE standard. Other implementers may replace this package with one of their own;for instance, one that uses native code to speed up the CPU-intensive key generation and encryption process

11. To Create a secure server socket in the reference implementation, you have to:
1. Generate public keys and certificates using keytool.
2. Pay money to have your certificates authenticated by a trusted third party such as Comodo.
3. Create an SSLContext for the algorithm you’ll use.
4. Create a TrustManagerFactory for the source of certificate material you’ll be using.
5. Create a KeyManagerFactory for the type of key material you’ll be using.

12. Create a KeyStore object for the key and certificate database
Create a KeyStore object for the key and certificate database. (Oracle’s default is JKS.) 7. Fill the KeyStore object with keys and certificates; for instance, by loading them from the filesystem using the passphrase they’re encrypted with. 8. Initialize the KeyManagerFactory with the KeyStore and its passphrase. 9. Initialize the context with the necessary key managers from the KeyManagerFactory, trust managers from the TrustManagerFactory, and a source of randomness.(The last two can be null if you’re willing to accept the defaults

13. SSL Certificate
An SSL-enabled client goes through the following steps to authenticate a server’s identity:
Is today’s date within the validity period?
The client checks the server certificate’s validity period. If the current date and time are outside of that range, the authentication process won’t go any further. If the current date and time are within the certificate’s validity period, the client goes on to the next step.
Is the issuing CA a trusted CA?
Each SSL-enabled client maintains a list of trusted CA certificates, represented by the shaded area on the right—hand side of Figure 5–9. This list determines which server certificates the client accepts. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client’s list of trusted CAs, the answer to this question is yes, and the client goes on to the next step. If the issuing CA is not on the list, the server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list.
Does the issuing CA’s public key validate the issuer’s digital signature?
The client uses the public key from the CA’s certificate (which it found in its list of trusted CAs in step 2) to validate the CA’s digital signature on the server certificate being presented. If the information in the server certificate has changed since it was signed by the CA or if the CA certificate’s public key doesn’t correspond to the private key used by the CA to sign the server certificate, the client won’t authenticate the server’s identity. If the CA’s digital signature can be validated, the server treats the user’s certificate as a valid “letter of introduction” from that CA and proceeds. At this point, the client has determined that the server certificate is valid.
Does the domain name in the server’s certificate match the domain name of the server itself?
This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as man-in-the-middle. Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don’t match. If the server’s actual domain name matches the domain name in the server certificate, the client goes on to the next step.
The server is authenticated.
The client proceeds with the SSL handshake. If the client doesn’t get to step 5 for any reason, the server identified by the certificate cannot be authenticated, and the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server requires client authentication, the server performs the steps described in Client Authentication During SSL Handshake.

14. /*The java.lang.Class class instance represent classes and interfaces in a running Java application.Class.forName(“className”) : Since class Class doesn’t contain any constructor, there is static factory method present in class Class, which is Class.forName() , used for creating object of class Class. The syntax is :Class c = Class.forName(String className)*/

15. 13
down vote
accepted
SSL Context is a collection of ciphers, protocol versions, trusted certificates, TLS options, TLS extensions etc. Since it is very common to have multiple connections with the same settings they are put together in a context and the relevant SSL connections are then created based on this context. And to create a new connection you need only refer to the context which thus saves time and memory compared to the case you would have to re-create of all these settings.

16. getInstance
public static SSLContext getInstance(String protocol)
throws NoSuchAlgorithmException
Returns a SSLContext object that implements the specified secure socket protocol.
This method traverses the list of registered security Providers, starting with the most preferred Provider. A new SSLContext object encapsulating the SSLContextSpi implementation from the first Provider that supports the specified protocol is returned.

17. The class HttpServer implements a simple HTTP server
The class HttpServer implements a simple HTTP server. A HttpServer is bound to an IP address and port number and listens for incoming TCP connections from clients on this address. The sub-class HttpsServer implements a server which handles HTTPS requests. One or more HttpHandler objects must be associated with a server in order to process requests. Each such HttpHandler is registered with a root URI path which represents the location of the application or service on this server. The mapping of a handler to a HttpServer is encapsulated by a HttpContext object. HttpContexts are created by calling createContext(String,HttpHandler). Any request for which no handler can be found is rejected with a 404 response. Management of threads can be done external to this object by providing a Executor object. If none is provided a default implementation is used. A HttpsServer must have an associated HttpsConfigurator object which is used to establish the SSL configuration for the SSL connections.