Appendix E <- index -> Normative References
（作業中）
The TLS protocol is designed to establish a secure connection between a client and a server communicating over an insecure channel。
This document makes several traditional assumptions, including that attackers have substantial computational resources and cannot obtain secret information from sources outside the protocol。
Attackers are assumed to have the ability to capture, modify, delete, replay,
and otherwise tamper with messages sent over the communication channel。
This appendix outlines how TLS has been designed to resist a variety of attacks。
F.1. Handshake Protocol English
（作業中）
The handshake protocol is responsible for selecting a cipher spec and generating a master secret, which together comprise the primary cryptographic parameters associated with a secure session。
The handshake protocol can also optionally authenticate parties who have certificates signed by a trusted certificate authority。
F.1.1. Authentication and Key Exchange English
（作業中）
TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity。
Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks。
Anonymous servers cannot authenticate clients。
If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority。
Similarly, authenticated clients must supply an acceptable certificate to the server。
Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked。The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers。
The pre_master_secret will be used to generate the master_secret (8.1 節を参照)。
The master_secret is required to generate the Finished messages, encryption keys, and MAC keys (7.4.9 節 と 6.3 節を参照)。
By sending a correct Finished message, parties thus prove that they know the correct pre_master_secret。
F.1.1.1. Anonymous Key Exchange English
（作業中）
Completely anonymous sessions can be established using Diffie-Hellman for key exchange。
The server's public parameters are contained in the server key exchange message, and the client's are sent in the client key exchange message。
Eavesdroppers who do not know the private values should not be able to find the Diffie-Hellman result (i.e., the pre_master_secret)。Warning: Completely anonymous connections only provide protection against passive eavesdropping。
Unless an independent tamper-proof channel is used to verify that the Finished messages were not replaced by an attacker, server authentication is required in environments where active man-in-the-middle attacks are a concern。
F.1.1.2. RSA Key Exchange and Authentication English
（作業中）
With RSA, key exchange and server authentication are combined。
The public key is contained in the server's certificate。
Note that compromise of the server's static RSA key results in a loss of confidentiality for all sessions protected under that static key。
TLS users desiring Perfect Forward Secrecy should use DHE cipher suites。
The damage done by exposure of a private key can be limited by changing one's private key (and certificate) frequently。After verifying the server's certificate, the client encrypts a pre_master_secret with the server's public key。
By successfully decoding the pre_master_secret and producing a correct Finished message, the server demonstrates that it knows the private key corresponding to the server certificate。When RSA is used for key exchange, clients are authenticated using the certificate verify message (7.4.8 節を参照)。
The client signs a value derived from all preceding handshake messages。
These handshake messages include the server certificate, which binds the signature to the server, and ServerHello.random, which binds the signature to the current handshake process。
F.1.1.3. Diffie-Hellman Key Exchange with Authentication English
（作業中）
When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSA or RSA certificate。
Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters。
In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server。If the client has a certificate containing fixed Diffie-Hellman parameters, its certificate contains the information required to complete the key exchange。
Note that
「 in this case the client and server will generate the same Diffie-Hellman result (i.e., pre_master_secret) every time they communicate」。
To prevent the pre_master_secret from staying in memory any longer than necessary,
it should be converted into the master_secret as soon as possible。
Client Diffie-Hellman parameters must be compatible with those supplied by the server for the key exchange to work。If the client has a standard DSA or RSA certificate or is unauthenticated, it sends a set of temporary parameters to the server in the client key exchange message, then optionally uses a certificate verify message to authenticate itself。
If the same DH keypair is to be used for multiple handshakes, either because the client or server has a certificate containing a fixed DH keypair or because the server is reusing DH keys, care must be taken to prevent small subgroup attacks。
Implementations SHOULD follow the guidelines found in [SUBGROUP]。Small subgroup attacks are most easily avoided by using one of the DHE cipher suites and generating a fresh DH private key (X) for each handshake。
If a suitable base (such as 2) is chosen, g^X mod p can be computed very quickly; therefore, the performance cost is minimized。
Additionally, using a fresh key for each handshake provides Perfect Forward Secrecy。
Implementations SHOULD generate a new X for each handshake when using DHE cipher suites。Because TLS allows the server to provide arbitrary DH groups,
the client は、
should verify that the DH group is of suitable size as defined by local policy。
The client は、
SHOULD also verify that the DH public exponent appears to be of adequate size。
[KEYSIZ] provides a useful guide to the strength of various group sizes。
The server MAY choose to assist the client by providing a known group, such as those defined in [IKEALG] or [MODP]。
These can be verified by simple comparison。
F.1.2. Version Rollback Attacks English
（作業中）
Because TLS includes substantial improvements over SSL Version 2.0, attackers may try to make TLS-capable clients and servers fall back to Version 2.0。
この攻撃は、
can occur if (and only if) two TLS-capable parties use an SSL 2.0 handshake。Although the solution using non-random PKCS #1 block type 2 message padding is inelegant,
it provides a reasonably secure way for Version 3.0 servers to detect the attack。
This solution is not secure against attackers who can brute-force the key and substitute a new ENCRYPTED-KEY-DATA message containing the same key (but with normal padding) before the application-specified wait threshold has expired。
Altering the padding of the least-significant 8 bytes of the PKCS padding does not impact security for the size of the signed hashes and RSA key lengths used in the protocol, since this is essentially equivalent to increasing the input block size by 8 bytes。
F.1.3. Detecting Attacks Against the Handshake Protocol English
（作業中）
An attacker might try to influence the handshake exchange to make the parties select different encryption algorithms than they would normally choose。
For this attack,
an 攻撃者 must actively change one or more handshake messages。
If this occurs, the client and server will compute different values for the handshake message hashes。
As a result, the parties will not accept each others' Finished messages。
Without the master_secret, the attacker cannot repair the Finished messages, so the attack will be discovered。
F.1.4. Resuming Sessions English
（作業中）
When a connection is established by resuming a session, new ClientHello.random and ServerHello.random values are hashed with the session's master_secret。
Provided that the master_secret has not been compromised and that the secure hash operations used to produce the encryption keys and MAC keys are secure, the connection should be secure and effectively independent from previous connections。
Attackers cannot use known encryption keys or MAC secrets to compromise the master_secret without breaking the secure hash operations。Sessions cannot be resumed unless both the client and server agree。
If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a full handshake。
An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired。
Applications that may be run in relatively insecure environments should not write session IDs to stable storage。
F.2. Protecting Application Data English
（作業中）
The master_secret is hashed with the ClientHello.random and ServerHello.random to produce unique data encryption keys and MAC secrets for each connection。
Outgoing data is protected with a MAC before transmission。
To prevent message replay or modification attacks, the MAC is computed from the MAC key, the sequence number, the message length, the message contents, and two fixed character strings。
The message type field is necessary to ensure that messages intended for one TLS record layer client are not redirected to another。
The sequence number ensures that attempts to delete or reorder messages will be detected。
Since sequence numbers are 64 bits long, they should never overflow。
Messages from one party cannot be inserted into the other's output, since they use independent MAC keys。
Similarly,
the server write and client write keys are independent, so stream cipher keys are used only once。If an attacker does break an encryption key, all messages encrypted with it can be read。
Similarly, compromise of a MAC key can make message-modification attacks possible。
Because MACs are also encrypted, message-alteration attacks generally require breaking the encryption algorithm as well as the MAC。注：
MAC keys は、
may be larger than encryption keys,
so messages can remain tamper resistant even if encryption keys are broken。
（作業中）
[CBCATT] describes a chosen plaintext attack on TLS that depends on knowing the IV for a record。
Previous versions of TLS [TLS1.0] used the CBC residue of the previous record as the IV and therefore enabled this attack。
This version uses an explicit IV in order to protect against this attack。
F.4. Security of Composite Cipher Modes English
（作業中）
TLS secures transmitted application data via the use of symmetric encryption and authentication functions defined in the negotiated cipher suite。
The objective is to protect both the integrity and confidentiality of the transmitted data from malicious actions by active attackers in the network。
It turns out that the order in which encryption and authentication functions are applied to the data plays an important role for achieving this goal [ENCAUTH]。The most robust method, called encrypt-then-authenticate,
first applies encryption to the data and then applies a MAC to the ciphertext。
This method ensures that the integrity and confidentiality goals are obtained with ANY pair of encryption and MAC functions, provided that the former is secure against chosen plaintext attacks and that the MAC is secure against chosen-message attacks。
TLS uses another method, called authenticate-then-encrypt, in which first a MAC is computed on the plaintext and then the concatenation of plaintext and MAC is encrypted。
This method has been proven secure for CERTAIN combinations of encryption functions and MAC functions, but it is not guaranteed to be secure in general。In particular, it has been shown that there exist perfectly secure encryption functions (secure even in the information-theoretic sense) that combined with any secure MAC function,
fail to provide the confidentiality goal against an active attack。
Therefore, new cipher suites and operation modes adopted into TLS need to be analyzed under the authenticate-then-encrypt method to verify that they achieve the stated integrity and confidentiality goals。Currently,
the security of the authenticate-then-encrypt method has been proven for some important cases。
One is the case of stream ciphers in which a computationally unpredictable pad of the length of the message, plus the length of the MAC tag, is produced using a pseudorandom generator and this pad is exclusive-ORed with the concatenation of plaintext and MAC tag。
The other is the case of CBC mode using a secure block cipher。
In this case,
security can be shown if one applies one CBC encryption pass to the concatenation of plaintext and MAC and uses a new, independent,
and unpredictable IV for each new pair of plaintext and MAC。
In versions of TLS prior to 1.1, CBC mode was used properly EXCEPT that it used a predictable IV in the form of the last block of the previous ciphertext。
This made TLS open to chosen plaintext attacks。
This version of the protocol is immune to those attacks。
For exact details in the encryption modes proven secure, see [ENCAUTH]。
F.5. Denial of Service English
（作業中）
TLS is susceptible to a number of denial-of-service (DoS) attacks。
In particular, an attacker who initiates a large number of TCP connections can cause a server to consume large amounts of CPU for doing RSA decryption。
However, because TLS is generally used over TCP, it is difficult for the attacker to hide his point of origin if proper TCP SYN randomization is used [SEQNUM] by the TCP stack。Because TLS runs over TCP, it is also susceptible to a number of DoS attacks on individual connections。
In particular,
attackers can forge RSTs, thereby terminating connections, or forge partial TLS records, thereby causing the connection to stall。
These attacks cannot in general be defended against by a TCP-using protocol。
Implementors or users who are concerned with this class of attack should use IPsec AH [AH] or ESP [ESP]。
（作業中）
For TLS to be able to provide a secure connection,
both the client and server systems, keys, and applications must be secure。
In addition,
the implementation must be free of security errors。The system is only as strong as the weakest key exchange and authentication algorithm supported, and only trustworthy cryptographic functions should be used。
Short public keys and anonymous servers should be used with great caution。
Implementations and users must be careful when deciding which certificates and certificate authorities are acceptable;
a dishonest certificate authority can do tremendous damage。
Appendix E <- index -> Normative References