The Basics of SSL/TLS
The following is a summary of the basics (without getting into the specifics). For a more
detailed description of the protocol visit"Wikipedia."
SSL is a framework for establishing a secure connection between two parties that wish to
communicate with each other. It is basically a conversation between the two parties during
which the two parties decide on what encryption ciphers each support, what key lengths to
use, encryption modes, certificates get exchanged, asymmetric encryption is used to agree
on a symmetric encryption key and then all subsequent communications are secured using
symmetric encryption. This conversation is called a"handshake.
The symmetric key generated during the handshake is only valid for the lifetime of the
SSL session. If the session does not remain active it will expire. A max lifetime can be set
after which the SSL session expires and a full handshake must again be established. Every
new SSL session will result in a new session / symmetric key.
Certicates and Keys
Before explaining SSL in more detail a quick summary of keys and certificates in
appropriate. Firstly SSL/TLS uses assymmetric encryption for authentication purposes
and to negotiate a symmetic key to be used for the SSL/TLS session.
Keys: Asymmetric encryption keys are generated in pairs - a private key and a
corresponding public key. Data encrypted with one can only be decrypted by the other.
Similarly data digitally signed with one can be verifier with the other. The private key, as
its name suggests, it is intended to be kept private and not disclosed.
Certificates: A certificate consists of a public encryption key conbines with some identity
information and an expiry date. A certificate also contains a digital signature of the
authority that issued the certificate. A certificate is typically issued to a web server,
application or a user and is a way to advertise the public encryption key."
If a client encrypts a message with a servers public key (from the servers certificate) they
the client can be assured that only the server can decrypt the message with the server's
private key (provided the server did not share the key). This is the basis for the
authentication that occurs. During the establishment of an SSL/TLS session key the client
creates and encrypts part of the session key. If the server is who he says he is, the server
should be able to decrypt the message with its private key and establish the session key."
But what if a hacker called Judas (not to be too dramatic!) created a Phishing website and
presented a bank's certificate to a client during an SSL/TLS handshake? Client browsers
would generate part of the session key, encrypt it and then present it to the server - but the
server would not be able to decrypt it without the corresponding private key and as such
would not be able to determine the session key proposed by the client. The result would be
我的内容管理
收起
我的收益 登录查看自己的收益
我的积分
登录查看自己的积分
我的C币
登录后查看C币余额
我的收藏 
我的下载 
下载帮助 
