Encryption, SSL/TLS, Secure Browsing

TLS runs on layers beneath application protocols such as HTTP, FTP, SMTP and above a reliable transport protocol, TCP . While it can add security to any protocol that uses reliable connections (such as TCP), it is most commonly used with HTTP to form HTTPS.

SSL/TLS works on the basis of public key cryptography.In “public key cryptography”, each person has two keys — a “public” key and a “private” key. Anything encrypted with the user’s public key can only be decrypted with the private key and vice versa. Each person then tells the world what his public key is and keeps his private key safe and secure, and private.
Once the connection is established between client and server, public key cryptography may not be used for actual information transmission.

Types of threat:
Eavesdropping(in transit)-- Encryption SSL/TLS will take care.
Re-routing for website-- Encryption SSL/TLS will take care.
Sending mail impersonating someone else-- Encryption SSL/TLS will not take care.

I am looking at TLS/SSL for secure messaging and for HTTPS.
SSL and TLS
1. Over HTTP(you and your mail server website, you and your bank website etc, where you are using browser)becomes HTTPS
2. Over SMTP(server to server like in case of Bank and other Bank)server to server SMTP.
3. Encrypted email even if I am using gmail or yahoo...how to do? client to server SMTP, server to server SMTP, Server to client POP3 or IMAP. Client here is email client(like outlook, thunderbird and Lotus Notes), not the browser client as in example 1, otherwise it will fall in example number 1 category.
For example 2 and 3:Secure messaging has two options- S/MIME and TLS. S/MIME involves users and is more reliable end to end sucure messaging. TLS does not involve users but is not ensured for secure messaging. If any chennel or server or client does not support TLS, message is insecure there. Moreover, TLS uses symmetrical key pair.
There are different types of authentication. HTTPS is example of unilateral authetication where server is autheticated but the client is not authenticated. There are certain transactions which happens between organisations where both client and server (server and server)are authenticated.
How example number 1(HTTP) works: http://en.wikipedia.org/wiki/Secure_Sockets_Layer TLS involves three basic phases:1. Peer negotiation for algorithm support 2. Key exchange and authentication 3. Symmetric cipher encryption and message authentication Typical algorithms are:
• For key exchange: RSA, Diffie-Hellman, ECDH, SRP, PSK
• For authentication: RSA, DSA, ECDSA
• Symmetric ciphers: RC4, Triple DES, AES, IDEA, DES, or Camellia. This clearly shows that different type encryption algorithm is in use. Symmetrical cipher(where same key is used to encrypt and decrypt), asymmetrical ciphers(a combination of public key and private keys) or both.Ciphers are the techniques for encryption. Asymmetrical cyphers or asymmetrical encryption uses only one key for encryption and decryption.
A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security.
• The handshake begins when a client connects to a TLS-enabled server requesting a secure connection, and presents a list of supported ciphers and hash functions.
• From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision.
• The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA), and the server's public encryption key. The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is authentic before proceeding.
• In order to generate the session keys used for the secure connection, the client encrypts a random number (RN) with the server's public key (PbK), and sends the result to the server. Only the server can decrypt it (with its private key (PvK)): this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data. The client knows PbK and RN, and the server knows PvK and (after decryption of the client's message) RN. A third party may only know PbK, unless PvK has been compromised.
• From the random number, both parties generate key material for encryption and decryption. This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.If any one of the above steps fails, the TLS handshake fails, and the connection is not created. Let’s see another more comprehensive example on how SSL actually works for securing your communications over the Internet. Before the communications occur, the following takes place:http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html
• A company wishes to secure communications to their server company.com.
• They create a public and private key for company.com (this is also known as a “certificate”).
• They go to a trusted third party company such as Thawte or Verisign: Thawte makes the company prove its identity and right to use the company.com domain. This usually involves a lot of paperwork and paying a hefty fee.
• Once the verification is complete, Thawte gives the company a new public key that has some additional information in it. This information is the certification from Thawte that this public key is for the company and company.com and that this is verified by Thawte. This certification information is encrypted using Thawte’s private key… we will see why below. Then, when Client wishes to communicate with the company at company.com,
• Client makes a connection to company.com with its computer. This connection is made to a special “port” (address) on company.com that is set up for SSL communications only.
• When Client connects to company.com on its SSL-secured port, the company sends back its public key.
• Client gets the public key and decides if it is OK…
• If the public key has expired, this could be a problem
• If the public key claims to be for some domain that is not company.com that could be a problem.
• Client has the public key for Thawte (and many other third party companies) stored in its computer — because these come with the computer. Thus, client can decrypt the validation information, prove the validation is from Thawte and verify that the public key is certified by Thawte. If Client trusts Thawte, then Client can trust that he/she is really communicating with Company. If Client doesn’t trust Thawte, or whatever Third Party company is actually being used, then the identity of who is running the computers to which Client is connecting is suspect.
• If client decides to trust the public key, then Client will send to the company the Client’s public key.
• The company will then generate a “password” and encrypt it using both Client’s public key and Company’s private key, in succession, and send it back to the client.
• Client will decrypt the password. This process proves that the company sent the password and that only Client was able to read it.
• Client will start communicating with the company by encrypting data using this password. Normal “symmetric” (password-based) encryption takes place from this point forward because it is much faster than using the public and private keys for everything. These keys were needed to enable the company to prove its identity and right to domain.com and to give client the password in a safe way.
Difference between SSL and TLS: http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html TLS allows both secure and insecure connections over the same port, whereas SSL requires a designated secure-only port. For users connecting to an email server via POP or IMAP, this means that using TLS will allow you to opt for secure connections but easily switch to insecure connections if necessary without needing to change ports. This is not possible with SSL. Remember your settings of Thunderbird where SSL port 995 is used for POP3 connection and not TLS.
TLS/SSL for secure messaging(SMTP)One way to secure SMTP is to require the use of Secure Sockets Layer (SSL) for SMTP connections. However, that approach raises a problem. By default, all SMTP servers use port 25. But if you use SSL on port 25, non-SSL servers won't be able to connect through that port. And if you use a nonstandard port number, other servers won't be able to find your servers.Here is the key difference between HTTPS and SMTP. HTTP and HTTPS works on different ports- 80 and 443 whereas SMTP with or without TLS, works on port 25 only.You can work around this problem. The STARTTLS verb (part of the Extended SMTP—ESMTP—command set) lets an SMTP client and server negotiate the use of Transport Layer Security (TLS) for an SMTP connection. Each end of the connection can choose to authenticate the other, or the TLS connection can be used purely for privacy. Either way, this approach offers three important advantages.
• It doesn't interfere with other servers and clients. Clients that support STARTTLS can use it; those that don't can continue to use unencrypted SMTP.
• It's opportunistic. When you enable the use of TLS with SMTP, your server automatically requests TLS when communicating with other servers, and it accepts TLS connections when requested. Assuming the other server completes the negotiation process, mail flow is automatically protected. (You'll generally need to tell your users to enable SSL/TLS in their Internet mail clients, though.)
• TLS-encrypting the SMTP stream also protects message headers, giving you an additional degree of protection against traffic analysis, which can tell network intruders who you're communicating with, and how often. You must remember one important caveat, however: TLS doesn't protect messages from end to end. In other words, it doesn't protect messages that are in storage or traveling from client to server (unless the client also supports TLS). TLS protects the message only as it passes between two servers that both support TLS.
Digital Signature:Digital signature is encrypting the mail using private key. Since the public is available publicly, it can be decrypted by anyone. But one thing is sure that the mail is sent by the intended sender only.This is one way to ensure the identity of the sender.
Classes for the certificates of various CAClass 1 for individuals, intended for email Class 2 for organizations, for which proof of identity is required Class 3 for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority This is used for google account/banks etcClass 4 for online business transactions between companies Class 5 for private organizations or governmental security.