A security protocol (cryptographic protocol or encryption protocol) is an abstract or concrete protocol that performs a security-related function and applies cryptographic methods. Cryptographic protocols are widely used for secure application-level data transport. A cryptographic protocol usually incorporates at least some of these aspects:
* Key agreement or establishment
* Entity authentication
* Symmetric encryption and message authentication
* Secured application-level data transport
* Non-repudiation methods
For example, Transport Layer Security (TLS) is a cryptographic protocol that is used, inter alia, to secure web (HTTP) connections. It has an entity authentication mechanism, based on the X.509 system; a key setup phase, where a symmetric encryption key is formed by employing public-key cryptography; and an application-level data transport function.
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols which provide secure communications and data transfer. There are slight differences between SSL 3.0 and TLS 1.0, but the protocol remains substantially the same. The term "TLS" as used here applies to both protocols unless clarified by context.
The TLS protocol(s) allow applications to communicate across a network in a way designed to prevent eavesdropping, tampering, and message forgery. TLS provides endpoint authentication and communications privacy over a network using cryptography. Typically, only the server is authenticated (i.e., its identity is ensured) while the client remains unauthenticated; this means that the end user (whether an individual or an application, such as a Web browser) can be sure with whom they are communicating. The next level of security - in which both ends of the "conversation" are sure with whom they are communicating - is known as mutual authentication. Mutual authentication requires public key infrastructure (PKI) deployment to clients.
TLS involves three basic phases:
Peer negotiation for algorithm support
Public key encryption-based key exchange and certificate-based authentication
Symmetric cipher-based traffic encryption
During the first phase, the client and server negotiation uses cryptographic algorithms. Current implementations support the following choices:
for public-key cryptography: RSA, Diffie-Hellman and DSA
for symmetric ciphers: RC2, RC4, IDEA, DES, Triple DES, AES or Camellia
for one-way hash functions: MD2, MD4, MD5 or SHA
Public key cryptography, also known as asymmetric cryptography, is a form of cryptography in which a user has a pair of cryptographic keys - a public key and a private key. The private key is kept secret, while the public key may be widely distributed. The keys are related mathematically, but the private key cannot be practically derived from the public key. A message encrypted with the public key can be decrypted only with the corresponding private key.
Conversely, Secret key cryptography, also known as symmetric cryptography uses a single secret key for both encryption and decryption.
The two main branches of public key cryptography are:
public key encryption
A message encrypted with a recipient's public key cannot be decrypted by anyone except the recipient possessing the corresponding private key. This is used to ensure confidentiality.
digital signatures
A message signed with a sender's private key can be verified by anyone who has access to the sender's public key, thereby proving that the sender signed it and that the message has not been tampered with. This is used to ensure authenticity.
An analogy for public-key encryption is that of a locked mailbox with a mail slot. The mail slot is exposed and accessible to the public; its location (the street address) is in essence the public key. Anyone knowing the street address can go to the door and drop a written message through the slot; however, only the person who possesses the key can open the mailbox and read the message.
An analogy for digital signatures is the sealing of an envelope with a personal wax seal. The message can be opened by anyone, but the presence of the seal authenticates the sender.
A central problem for public-key cryptography is proving that a public key is authentic, and has not been tampered with or replaced by a malicious third party. The usual approach to this problem is to use a public-key infrastructure (PKI), in which one or more third parties, known as certificate authorities, certify ownership of key pairs. Another approach, used by PGP, is the "web of trust" method to ensure authenticity of key pairs.
Public key techniques are much more computationally intensive than purely symmetric algorithms. The judicious use of these techniques enables a wide variety of applications. In practice, public key cryptography is used in combination with secret-key methods for efficiency reasons. For encryption, the message may be encrypted with secret-key algorithm using a randomly generated key, and that key encrypted with the user's public key. For digital signatures, a message is hashed (using a cryptographic hash function) and the smaller "hash value" is signed; before verifying the signature, the recipient computes the hash of the message himself, and compares this hash value with the signed hash value to check that the message has not been tampered with.
A big random number is used to make a public-key pair.
Anyone can encrypt using the public key, but only the holder of the private key can decrypt. Secrecy depends on the secrecy of the private key.
Using a private key to encrypt (thus signing) a message; anyone can check the signature using the public key. Validity depends on private key security.
By combining your own private key with the other user's public key, you can calculate a shared secret that only the two of you know. The shared secret can be used as the key for a symmetric cipher.
The binding between a public key and its 'owner' must be correct. As with most cryptography, the protocols used to establish and verify this binding are critically important. Associating a public key with its owner is typically done by protocols implementing a public key infrastructure; these allow the validity of the association to be formally verified by reference to a trusted third party, either in the form of a hierarchical certificate authority (e.g., X.509), a local trust model (e.g., SPKI), or a web of trust scheme (e.g., that originally built into PGP and GPG ).
The TLS protocol exchanges records; each record can be optionally compressed, appended with a message authentication code (MAC), and encrypted. Each record has a content type field that specifies which upper level protocol is being used. When the connection starts, the record level encapsulates another protocol, the handshake protocol, which has content type 22.
A typical handshake proceeds as follows:
A Client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
The Server responds with a ServerHello, containing the chosen protocol version, a random number, cipher, and compression method from the choices offered by the client.
The Server sends its Certificate (depending on the selected cipher, this may be omitted by the Server). These certificates are currently X.509, but there is also a draft specifying the use of OpenPGP based certificates.
The server may request a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest.
The Server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
The Client responds with a ClientKeyExchange which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher).
The Client and Server then use the random numbers and PreMasterSecret to compute a common secret called the "master secret". All other key data is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed "pseudorandom function".
The Client now sends a ChangeCipherSpec message, essentially telling the Server, "everything I tell you from now on will be encrypted." Note that the ChangeCipherSpec is itself a Record Layer protocol, and has type 20, and not 22.
Finally, the Client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
The Server will attempt to decrypt the Client's Finished message, and verify the hash and MAC. If the decryption or verification fails, the handshake is considered failed and the connection should be torn down.
Finally, the Server sends a ChangeCipherSpec and its encrypted Finished message, and the Client performs the same decryption and verification.
At this point, the "handshake" is complete and the Application protocol is enabled, with content type of 23. Application messages exchanged between Client and Server will be encrypted.
Given the above recount of a TLS/SSL connection process, one may have trouble envisioning a typical browser session. To elaborate upon this and to give ordinary insight to a typical TLS/SSL connection we can use what is commonly referred to as the SSL six step process. SSL establishes a stateful connection negotiated by a handshaking procedure between client and server as previously mentioned. During this handshake, the client and server exchange specifications for the cipher that will be used for that session.
The handshake begins when a browser connects to a TLS/SSL-enabled server and requests that the server send back its identification.
The server sends back its identification in the secured form of a digital certificate. The certificate will contain (usually all of these variables, but dependent on the X.509 standard used) the server name, the trusted certificate authority (CA), and the server public encryption key.
The browser may contact the server of the trusted CA and confirm that the certificate is authentic before proceeding. The browser then presents a list of encryption algorithms and hashing functions (used to generate a number from another).
From this list the server picks the strongest encryption that it also supports and notifies the client of the decision.
In order to generate the session keys used for the secure connection, the browser uses the server public key from the certificate to encrypt a random number and send it to the server.
The client can encrypt this data, but only the server can decrypt it (with its private key): 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 server replies with more random data (which doesn't have to be encrypted), and following this: Both parties use the selected hash functions on the random data to generate the session keys.
This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the session keys for the remainder. If any one of the steps in previous mention fails, the TLS/SSL handshake fails, and the connection is not created.
TLS runs on layers beneath application protocols such as HTTP, FTP, SMTP, NNTP, and XMPP and above a reliable transport protocol, TCP for example. 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. HTTPS is used to secure World Wide Web pages for applications such as electronic commerce and asset management. SMTP is also an area in which TLS has been growing and is specified in RFC 3207. These applications use public key certificates to verify the identity of endpoints.
An increasing number of client and server products support TLS natively, but many still lack support. As an alternative, users may wish to use standalone TLS products like Stunnel. Wrappers such as Stunnel rely on being able to obtain a TLS connection immediately, by simply connecting to a separate port reserved for the purpose. For example, by default the TCP port for HTTPS is 443, to distinguish it from HTTP on port 80.
TLS can also be used to tunnel an entire network stack to create a VPN, as is the case with OpenVPN. Many vendors now marry TLS's encryption and authentication capabilities with authorization. There has also been substantial development since the late 1990s in creating client technology outside of the browser to enable support for client/server applications. When compared against traditional IPSec VPN technologies, TLS has some inherent advantages in firewall and NAT traversal that make it easier to administer for large remote access populations.
Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary. SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; it can transfer files using the associated SFTP or SCP protocols.
An SSH server, by default, listens on the standard TCP port 22.
An ssh client program is typically used for establishing connections to an sshd daemon accepting remote connections. Both are commonly present on most modern operating systems, including Microsoft Windows, Mac OS X, Linux, Solaris and OpenVMS.
SSH is most commonly used for the following applications:
With an SSH client that supports terminal protocols, for remote administration of the SSH server computer via terminal console.
In combination with SFTP, as a secure alternative to FTP which can be set up more easily on a small scale without a public key infrastructure and X.509 certificates.
In combination with rsync to backup, copy and mirror files efficiently and securely
Port forwarding or tunneling, frequently as an alternative to a full-fledged VPN. In this type of use, a (non-secure) TCP/IP connection of an external application is redirected to the SSH program (client or server), which forwards it to the other SSH party (server or client), which in turn forwards the connection to the desired destination host. The forwarded connection is encrypted and protected on the path between the SSH client and server only. Uses of SSH port forwarding include accessing database servers, email servers, securing X11, Windows Remote Desktop and VNC connections or even forwarding Windows file shares. This is primarily useful for tunneling connections through firewalls which would ordinarily block that type of connection, and for encrypting protocols which are not normally encrypted.
Since SSH-1 has inherent design flaws which make it vulnerable to, e.g., man in the middle attacks, it is now generally considered obsolete and should be avoided by explicitly disabling fallback to SSH-1. While most modern servers and clients support SSH-2, some organizations still use software with no support for SSH-2 making it hard to avoid the use of SSH-1.
In all versions of SSH, it is important to verify unknown public keys before accepting them as valid. Accepting an attacker's public key as a valid public key has the effect of disclosing the transmitted password and allowing man in the middle attacks.
Widely used user authentication methods include the following:
"password": a method for straightforward password authentication, including a facility allowing a password to be changed. This method is not implemented by all programs.
"publickey": a method for public key-based authentication, usually supporting at least DSA or RSA keypairs, with other implementations also supporting X.509 certificates.
"keyboard-interactive": a versatile method where the server sends one or more prompts to enter information and the client displays them and sends back responses keyed-in by the user.
GSSAPI (Generic Security Services Application Program Interface) authentication methods which provide an extensible scheme to perform SSH authentication using external mechanisms such as Kerberos 5 or NTLM (NT Lan Manager), providing single sign on capability to SSH sessions. These methods are usually implemented by commercial SSH implementations for use in organizations, though OpenSSH does have a working GSSAPI implementation.
SSH File Transfer Protocol or SFTP is a network protocol that provides file transfer and manipulation functionality over any reliable data stream. A common misconception is that SFTP is simply FTP run over SSH; in fact it is a new protocol designed from the ground up. The protocol itself does not provide authentication and security; it expects the underlying protocol to secure this. SFTP is most often used as subsystem of SSH protocol version 2 implementations,
Compared to the earlier, deprecated, SCP protocol, which allows only file transfers, the SFTP protocol allows for a range of operations on remote files - it is more like a remote file system protocol. An SFTP client's extra capabilities compared to an SCP client include resuming interrupted transfers, directory listings, and remote file removal. The protocol is not yet an Internet standard. Currently the most widely used version is 3, implemented by the popular OpenSSH SFTP server. Many Microsoft Windows-based SFTP implementations use version 4 of the protocol, which lessened its ties with the Unix platform
HTTPS is a URI scheme used to indicate a secure HTTP connection. It is syntactically identical to the http:// scheme normally used for accessing resources using HTTP. Using an https: URL indicates that HTTP is to be used, but with a different default TCP port (443) and an additional encryption/authentication layer between the HTTP and TCP.
Strictly speaking, https is not a separate protocol, but refers to the combination of a normal HTTP interaction over an encrypted Secure Sockets Layer (SSL) or Transport Layer Security (TLS) transport mechanism. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks.
To prepare a web-server for accepting https connections the administrator must create a public key certificate for the web-server. These certificates can be created for Unix based servers with tools such as OpenSSL's ssl-ca or SuSE's gensslcert. This certificate must be signed by a certificate authority of one form or another, who certifies that the certificate holder is who they say they are. Web browsers are generally distributed with the signing certificates of major certificate authorities, so that they can verify certificates signed by them.
Organizations may also run their own certificate authority, particularly if they are responsible for setting up browsers to access their own sites (for example, sites on a company intranet), as they can trivially add their own signing certificate to the defaults shipped with the browser. Some sites use self signed certificates. Using these provides protection against pure eavesdropping but unless the certificate is verified by some other method (for example, phoning the certificate owner to verify its checksum) and that other method is secure, there is a risk of a man-in-the-middle attack.
The system can also be used for client authentication, in order to restrict access to a Web server to only authorized users. For this, typically the site administrator creates certificates for each user which are loaded into their browser, although certificates signed by any certificate authority the server trusts should work. These normally contain the name and e-mail of the authorized user, and are automatically checked by the server on each reconnect to verify the user's identity, potentially without ever entering a password.