Cryptography Reference
In-Depth Information
its security properties overestimated under the misapprehension that use of
SSL 'guarantees' security. Perhaps the classic example of the latter is our
default SSL application of securing the connection between a client web
browser and the web server of an online store. Such stores often claim to
offer a 'completely secure' service because they are deploying SSL. This of
course tells the client nothing about the security of their payment card details
after the web server has acquired them. After all, largely due to the use of
SSL, criminals seeking payment card details are more likely to hack into a
back-end database, rather than engage in large-scale monitoring of network
traffic.
12.1.7
SSL design issues
Having discussed the use of cryptography in SSL at some length, we close by
remarking on a few of the design issues that appear to have influenced the
cryptographic choices made by the designers of SSL.
Support for a range of publicly known cryptographic algorithms
. Since SSL (in
this case we really mean TLS) is an open standard targeted at wide-scale public
use, it is fundamental that it supports not just publicly known algorithms, but
a
range of
publicly known algorithms. This supports cross-platform use and
has helped to foster confidence in SSL as a protocol.
Flexibility
. SSL is not only flexible in terms of the components that can be
used to implement it, but it is also flexible in the ways in which it can be
used (for example, to provide unilateral or mutual entity authentication).
This, again, is because SSL has been targeted at a wide range of application
environments.
Minimal use of public-key operations
. The use of hybrid encryption restricts
the number of public-key operations to the minimum necessary to establish
a secure channel. Although we have not discussed this in any detail, SSL is
also designed so that the relatively expensive SSL Handshake Protocol may not
need to be rerun if a client requires another session with the same server within
a specified time period.
Unbalanced computational requirements
. Recall that in the SSL Handshake
Protocol it is the client who is required to generate the pre-master secret and
send it encrypted to the server. This means that the client performs one public-
key
encryption
operation and the server performs one public-key
decryption
operation. One reason for this is that some public-key cryptosystems, and
RSA is a good example, have certain public keys that are considerably
more computationally efficient to use than others (see Section 10.3.4).
Thus it is reasonable to assume that encryption is a faster operation than
decryption. The design of SSL thus places a slight computational 'burden' on
the server, which is the entity expected to have the greater computational
ability.
