Ведущий Диалог
Зарегистрирован:
24 December 2005
Сообщения: 189
Примеры кода: 0
|
Re: Насколько HTTPS защищенный протокол? Или это просто прикол? |
16 November 2007 09:12 |
|
|
|
|
Пост большой, виноват. Не удержался.
The Secure Sockets Layer protocol has been in use for Web commerce
for three years now(year 2000), and under its new name of Transport
Layer Security, the protocol is now in its fourth revision. Engineers
now have quite a lot of experience with ssl and tls implementations,
much of which has helped to improve the security of the protocol
through its revisions. Security specialists have also learned quite
a lot about the relationship of ssl to other aspects of the systems that
implement it. In fact, although there are no known security flaws in
the ssl or tls protocols themselves, other weaknesses in systems using
ssl have been successfully exploited, at least in academic or research
environments. This appendix considers those other
weaknesses. It presents them in the form of an ssl security checklist,
primarily for those readers who are designing or evaluating ssl implementations.
Of course, the following list is not exhaustive, and
new threats and attacks are likely to arise in the future. Readers
should certainly stay up to date with security news and events to
make sure that their implementations do not become vulnerable as
new attacks are discovered.
This appendix considers security issues related to both the authentication
and the encryption services of ssl. Each service receives its
own section. In some cases, the distinction between the two is a bit
artificial, as several issues have important effects for both services.
For these, the appendix concludes with a section of general issues
that are not easily characterized.
B.1 Authentication Issues
Authentication often seems to take a back seat to encryption in security
discussions, especially in the trade press, where reports of crack
ing cryptographic algorithms receive prominent coverage. Ultimately,
however, authentication is more critical to security. How secure, after
all, is a system that establishes full-strength, encrypted communications
with an attacker masquerading as the intended recipient? No
amount of encryption can prevent an unsuspecting party sending an
unauthenticated (or improperly authenticated) attacker the session
keys. Although it may be tempting to overlook them, addressing authentication
issues is vital to secure communication.
As this section makes clear, many of the issues of ssl authentication
revolve around x.509 certificates. There are, however, some authentication
issues specific to ssl that are independent of public key certificates.
B.1.1 Certificate Authority
A certificate authority (ca) signs all x.509 certificates, and any ssl
implementation must decide whether it can trust the ca of its communicating
peer. Typically, implementations compare the peer’s ca
with an internal list of authorities that the implementation “knows”
to be trustworthy. With this approach, it is important that the implementation
use the public key from its internal store to verify the
certificate, rather than the public key from the ca certificate provided
by the peer. Attackers can construct fake ca certificates that are identical
to real certificates in all areas except the public key, substituting
a public key corresponding to the attacker’s private key. Only by retrieving
ca public keys from its internal store would an implementation
prevent such an attack.
If an implementation does decide to keep an internal list of trusted
certificate authorities, it must carefully consider how, if at all, it will
allow users to update that list. For short-lived implementations, such
updates may not be needed. In general, however, users will need a
way to revise the set of trusted authorities. Even ca certificates, for
example, expire eventually.
B.1.2 Certificate Signature
This point may seem obvious, but it can be easy to overlook: an ssl
implementation must validate all certificates it receives by verifying
the ca signature within them.
B.1.3 Certificate Validity Times
All ssl implementations should also check the validity period for all
certificates. The validity period includes both a “not before” and a
“not after” time; both should be verified. As an additional twist, note
that the asn.1 object used for time in x.509 certificates (the utctime
string) only provides two decimal digits for the year. All appropriate
y2k concerns apply.
B.1.4 Certificate Revocation Status
Implementations that operate in environments that support certificate
revocation should check the revocation status of any certificate
before accepting it. Unfortunately, not all environments effectively
support certificate revocation. The Web, for example, does not have a
widely deployed mechanism for disseminating certificate revocation
lists. In such cases, an implementation may want to provide users an
alternative, perhaps by permitting the manual import of certificate
revocation lists.
B.1.5 Certificate Subject
Perhaps it should go without saying, but an implementation must not
only ensure that a certificate is valid; the implementation must also
make sure that it certifies the right party. An attacker may well be
able to get a perfectly valid certificate from a legitimate certificate
authority. That certificate will simply be a certificate for the attacker.
An implementation that tries to communicate with confidant.com,
and instead receives a certificate for evilhacker.com, had better notice
the discrepancy, no matter how valid the certificate.
164 SSL & TLS Essentials: Securing the Web
Exactly how an implementation verifies that the certificate is for the
intended subject depends on the policies of the certificate authority.
VeriSign Class 3 certificates, for example, place the host name of the
certified Web site in the commonName field of the certificate’s subject.
Both Netscape Navigator and Internet Explorer check this field
against the host name that the user enters in the url (or that appears
in the referring link).
B.1.6 Diffie-Hellman Trapdoors
When ssl implementations use ephemeral Diffie-Hellman key exchange,
the server specifies a full set of Diffie-Hellman parameters.
There are, however, legitimate disagreements about what constitutes
sufficiently secure Diffie-Hellman parameters.1 Clients that support
ephemeral Diffie-Hellman key exchange should check the parameters
they receive from the server. They should ensure that the server
has chosen values that the client believes will provide adequate security.
B.1.7 Algorithm Rollback
With a ServerKeyExchange message, an ssl server sends the client
public key information the client needs to encrypt the premaster secret
for the server. This key information is signed by the server using
the private key corresponding to the public key in the server’s Certificate
message. The public key algorithm the client is to use, however,
is not specified explicitly in the ServerKeyExchange message, so
that information is not signed by the server. This could make the ssl
protocol vulnerable to an algorithm rollback attack.
In an algorithm rollback attack, the attacker forces the two parties to
have different opinions as to which public key algorithm is to be used
to sign the premaster secret. The client, for example, might be fooled
into believing that rsa encryption is appropriate, while the server expects
Diffie-Hellman. David Wagner and Bruce Schneier show how
this scenario leads to a complete breakdown of all cryptographic
protection. The attacker is able to read all information for the session
or to forge fake data in the name of either party.
To protect against this algorithm rollback attack, ssl client implementations
should verify the length and number of parameters in any
ServerKeyExchange message. As figures 4-10 and 4-11 indicated, rsa
encryption requires only two parameters, while Diffie-Hellman uses
three. If, in any received message, the lengths of the individual parameters
and the signed hash values do not add up to the correct
length of the whole message, then the client should reject the session
and generate an appropriate alert.
B.1.8 Dropped ChangeCipherSpec Messages
The ssl protocol does not include ChangeCipherSpec messages in
the handshake authentication code that Finished messages carry.
ChangeCipherSpec messages are omitted because ssl does not consider
them to be Handshake protocol messages. (Recall that
ChangeCipherSpec messages belong to their own separate ssl subprotocol.)
This omission does leave ssl implementations vulnerable
to a particular attack when the parties use authentication-only (i.e.,
no encryption) sessions.
To take advantage of this vulnerability, the attacker simply deletes
the ChangeCipherSpec messages from the communication stream.
Both parties will receive an apparently valid Finished message and
begin transferring application data, without ever activating the cipher
suite they have negotiated. (This attack is not feasible when the session
uses encryption. In that case, the party sending a Finished message
will encrypt it, while the party receiving the Finished message,
not having seen the missing ChangeCipherSpec message, will expect
it unencrypted.)
Fortunately, combating this attack is very straightforward. An ssl
implementation should not accept a Finished message unless it has
also received a ChangeCipherSpec message.
B.2 Encryption Issues
Aside from the contentious legal issues that can limit the effectiveness
of any security implementation, ssl is very effective in protecting
the confidentiality of information. There are a few minor points
to consider, however. This section reviews the importance of encryption
key size, and examines two other concerns about ssl encryption:
a potential traffic analysis weakness and an attack first identified by
Daniel Bleichenbacher.
B.2.1 Encryption Key Size
One important issue that arises repeatedly is the strength of the encryption
that ssl offers. That strength depends most directly on the
size of the keys used by the symmetric encryption algorithms, such as
rc4 and des. In theory, developers could create ssl implementations
that only used sufficiently large key sizes, and such implementations
would be practically unbreakable. Some governments, however, place
restrictions on the use or export of cryptography. The laws and regulations
of the United States (home to many key ssl developers)
forced the creation of the “export strength” ssl cipher suites, which,
because of their limited key size, are much weaker than the protocol
allows. Indeed, sessions encrypted using these cipher suites were successfully
attacked as early as 1995, and most security professionals
today consider the ssl export strength cipher suites to offer only
marginal security. The situation did not improve significantly when
the u.s. government relaxed its regulations to allow export of stronger
cryptography. The stronger 56-bit encryption was compromised in
1998.
Secure Socket Layer implementations should carefully evaluate the
value of the information they will protect and weigh that against the
strength of the security they can offer. If the information is sufficiently
valuable, and if the implementation would be subject to laws
or regulations that would restrict its encryption strength, compromise
solutions might be the most viable. Netscape’s International Step-Up
and Microsoft’s Server Gated Cryptography are both examples of
how stronger security is possible in the context of laws and regulations.
B.2.2 Traffic Analysis
Attackers may learn a lot about a target just by observing the traffic
to and from that target, even if they cannot actually decrypt the information.
Traffic analysis, as such attacks are known, is difficult to
defend against in an open environment such as the Internet. (Indeed,
many Web sites like to publicize the amount and type of traffic they
receive.) In any environment, however, the ssl protocol itself introduces
an additional traffic analysis vulnerability. When ssl uses a
stream cipher for encryption, the size of the encrypted messages can
reveal the size of the unencrypted data; the attacker needs only to
subtract the size of the message authentication code. Bennet Yee has
noted how this weakness could allow an attacker to discover some information
about an encrypted session, including, for example, which
specific Web pages were retrieved by a user (though not the contents
of those pages). This weakness is not present if block encryption ciphers
are used, since the padding they introduce effectively hides the
exact size of the plaintext data. If the application warrants it, ssl im-
plementations may choose to support only block encryption cipher
suites in order to protect against this traffic analysis attack.
B.2.3 The Bleichenbacher Attack
In 1998, Daniel Bleichenbacher, a researcher at Lucent’s Bell Laboratories,
reported a specific active attack against security protocols that
use rsa encryption, including the ssl protocol.6 The attack takes advantage
of the way the rsa encryption algorithm encodes data before
encrypting it. The encoded data (which ssl uses as a symmetric encryption
key) always begins with the two bytes 00 and 02. Table b-1
shows how an attacker can exploit this characteristic.
Table B-1 The Bleichenbacher Attack
Step Action
1 The attacker carefully constructs many artificial ciphertext
blocks and sends them to the target. (Since the attacker doesn’t
know the target’s private key, the attacker won’t know how
these ciphertext blocks will be decrypted. At this point, that is
not important, though.)
2 The target receives the artificial ciphertext blocks and decrypts
them.
a For most of the blocks, the resulting “plaintext” will not conform
to the RSA encoding format. (It won’t begin with the bytes
00 and 02.) In those cases, the target generates an error or perhaps
ignores the communication.
b Occasionally a ciphertext block will happen to decrypt into
plaintext that begins with the magic 00 and 02 bytes. In those
cases, the target treats the decryption as successful and attempts
to use the rest of the “plaintext” for its intended purpose.
(Since the plaintext is effectively just random data, the
target is likely to eventually realize that something is wrong
with its data. By that time, however, it may be too late.)
3 The attacker observes the target’s reaction to each artificial ciphertext
block, noting which blocks cause response 2a and
which cause response 2b.
4 By carefully choosing its artificial ciphertext blocks, and by refining
those choices as the attack progresses, the attacker can
use sophisticated mathematical analyses to decipher a related
ciphertext block, perhaps one that was actually sent to the target
as part of legitimate communications.
In practice, Bleichenbacher’s strategy does have a significant limitation.
The number of artificial ciphertext blocks it requires can be
quite large. For a 1024-bit rsa modulus (the standard key size for
Web security not subject to u.s. export restrictions), the attacker
must generate about 220 (just over 1 million) different artificial ciphertext
blocks. This limitation will likely warn any reasonably vigilant
target that an attack may be under way.
In addition, there are several other steps that ssl implementations
can take to reduce their exposure to this attack. One step is to rigorously
check the decrypted plaintext before accepting it as a valid decryption.
In the case of received ClientKeyExchange messages,
implementations should ensure that the premaster secret is the correct
size (48 bytes) and that the first 2 bytes are the ssl version number,
in addition to verifying the presence of the 00 and 02 bytes.
Those steps alone will increase the number of artificial ciphertext
blocks the attack requires from 220 to more than 240 (about 20 million).
Another design principle that can thwart this attack is to be very parsimonious
in sending error responses. Ideally, an ssl implementation
would behave consistently, whether it was unable to decrypt a ClientKeyExchange
message or it decrypted successfully but found the
resulting plaintext to be invalid. One possible implementation is to
ignore the fact that decrypted ClientKeyExchange data does not
conform to the rsa encoding format. (In other words, it does not begin
with 00 02.) A convenient way to achieve this may be to replace
any such invalid data with random data that does conform. The server
will then detect and respond to the error just as if the invalid data
had been appropriately formatted.
Finally, please note that the symmetric encryption key that is encrypted
by the rsa algorithm is the only information at risk from this
attack. The attack does not compromise any rsa private keys.
B.3 General Issues
A few important issues do not easily fit the categories of either authentication
or encryption. This section discusses those issues, including
the problems of rsa key size, version rollback attacks,
premature closures, session id values, random number generation,
and random number seeding.
B.3.1 RSA Key Size
The majority of ssl implementations today use the rsa encryption
algorithm for digital signatures and public key encryption. The
strength of the rsa algorithm depends directly on the size of the rsa
public key. Longer keys yield more secure implementations. As the
availability of computing power has increased and its cost has decreased,
key sizes that were once thought adequately secure are now
susceptible to brute-force attacks. While the author was preparing
this manuscript, a team of researchers announced that they had successfully
cracked an rsa key of 512 bits,7 the same key size that (due
to u.s. export restrictions) is commonly used to secure most Web
transactions. The team used several hundred computers full-time for
seven months, so there may not be an immediate practical threat to
existing systems, but rsa Laboratories recommends 768 bits as the
minimum acceptable key size for the rsa algorithm.
It is important to understand that a weakness or compromise of the
rsa algorithm may be far more severe than one in symmetric encryp-
tion algorithms such as rc4 or des. Symmetric algorithms provide
the encryption for individual ssl sessions. If a particular symmetric
encryption key is compromised, only information from the session
that used the key is exposed. The rsa public key algorithm, however,
is used both to authenticate parties and to securely exchange all session
keys. If a particular rsa private key is compromised, then the
owner of that key is vulnerable to impersonation, and the information
from all ssl sessions with that party may be exposed.
B.3.2 Version Rollback Attacks
Secure Sockets Layer version 3.0 introduced several improvements to
version 2.0, including those that increased the security of the protocol.
It is important, therefore, that two parties that are capable of using
version 3.0 actually do so, instead of falling back to the less secure
version 2.0. As section 5.1.1 indicated, the ssl specification outlines a
very specific approach to protect against attacks that force a version
rollback. There is, however, one area that the specification does not
address: resumption of prior sessions. A cursory ssl implementation
might allow a session that had previously been established using version
3.0 to be resumed using version 2.0. Such an implementation
would comply with the ssl standard. Careful implementations,
though, should not allow this behavior. If a session is established using
ssl version 3.0, then the implementation should ensure that all
attempts to resume the session also use ssl version 3.0.
B.3.3 Premature Closure
Another general security issue is the threat of truncation attacks due
to the premature closure of an ssl session. If an attacker can delete
protocol messages in transit, that attacker could create a scenario in
which one or both of the communicating parties only receive partial
information. If the missing information is vital to the communications,
the attacker will have compromised the overall security of the
exchange. As section 3.4 discussed, the ssl protocol defines the ClosureAlert
message to protect against this type of attack. (Although
the ClosureAlert can’t prevent the attack, the absence of a ClosureAlert
message at least alerts the parties to the potential problem.)
Unfortunately, not all environments can rely on the ClosureAlert.
Web browsing users, for example, may simply turn off their personal
computer after completing a transaction, before that computer has a
chance to send a ClosureAlert message. More thorough protection
requires that applications using ssl security be sensitive to the possibility
of premature closures. Web servers that support the HyperText
Transfer Protocol (http), for example, include a Content-Length
field with each page they send to a client. Clients should verify that
the amount of data they receive is consistent with this field’s value.
B.3.4 SessionID Values
The ssl specification gives servers complete flexibility to choose particular
SessionID values. In making this choice, server implementation
should be careful not to include any critical security information.
SessionID values are transferred in ClientHello and ServerHello
messages before any encryption is active. Their values, therefore, are
completely exposed to any potential attacker.
B.3.5 Random Number Generation
Random numbers are critical to the operation of the Secure Sockets
Layer protocol. The random numbers exchanged in ClientHello and
ServerHello messages ultimately determine the encryption key for
the session. Random numbers, however, present an interesting challenge
to computer systems; software cannot do anything truly randomly.
Instead, software implementations typically rely on
algorithms known as pseudorandom number generators. These algorithms
simulate true randomness with complex mathematical calculations.
There are two problems with pseudorandom number generators that
should concern ssl and other security implementations. The first
problem is the effectiveness of the algorithms themselves. Most
software libraries generate pseudorandom numbers using a linear
congruential generator algorithm. Although such algorithms can be effective
pseudorandom number generators, they can also be quite
ineffective. Furthermore, many developers seek to improve on the
effective. Furthermore, many developers seek to improve on the basic
algorithm in ways that can, in fact, be quite disastrous. Press, Teukolsky,
Vetterling, and Flannery report on one widely used pseudorandom
number generator that, in an extreme case, effectively generated
only 11 distinct random values.
A more serious problem with linear congruential generators is that
they are sequential, and completely predictable. If you know the parameters
of the algorithm and one specific value, it is easy to predict
all future values that the algorithm will generate. Predictable random
numbers are a serious problem for any security protocol, as they allow
attackers to plan and prepare well into the future, waiting, perhaps,
for a single, compromised value to appear. Implementations of ssl,
therefore, should be careful not to use common pseudorandom number
generator libraries. Fortunately, standard cryptography algorithms,
including both encryption and hash algorithms, can be
modified to provide effective random numbers.
B.3.6 Random Number Seeding
Regardless of the algorithm implementations used to generate random
numbers, implementations typically must provide that algorithm
with an initial starting point, or seed. For applications other
than security, the primary requirement for this seed is that it be different
each time it is generated. That ensures, for example, that a
computer game does not act the same at each playing. That has led
many developers to use some form of the time of day as the seed. For
security applications, however, random seeds not only must be different,
they must also be unpredictable. The time of day is rarely unpredictable.
Indeed, Matthew Schmid reports a successful attack
against several online gambling sites that rely on flawed software for
their online poker games. The software used the time of day to seed
its random number generator and, as a result, attackers were able to
successfully predict the cards in every player’s hand. Although not
strictly ssl-related, the lesson is clear: using the time of day for random
seeds is totally unacceptable for ssl implementations.
Данное сообщение получено с сайта GotDotNet.RU
|
|