next up previous
Next: 4.2 Security Assessment of Up: 4.1 Security Assessment of Previous: 4.1.2 Security Service Requirements

4.1.3 Other Factors

* Proxy Operation

There are substantial issues associated with the use of SSL in a proxy/firewall environment. SSL is intended to create a secure channel between transport peers. HTTP proxies expect to operate on application data. Consequently, there are two choices for proxy operation. Either an SSL association can be established through the proxy and viewed as an opaque hole through the proxy machine or the proxy can establish SSL associations with the client and/or server. In either of these scenarios, the proxy must be SSL aware.

In the case of allowing an SSL association to be established through the firewall, the security services are provided between the end client and server. There are two concerns with respect to the proxy itself. First, there is no way for the firewall to determine what information is flowing through the SSL pipe. This amounts to a wide open door into the protected environment and is a significant issue. The second concern is the ability of the HTTP proxy to perform any application based functions (e.g., access control, filtering, caching). If the SSL association is made through the proxy, no application based processing can be performed (in fact, the proxy has no way of telling that HTTP transactions are being exchanged).

If the proxy establishes the SSL association(s), then the proxy can perform all of its normal processing (SSL becomes a specialized access method). However, the security services are terminated at the proxy. Consequently, all information is exposed at the proxy and the authentication is limited to the identity of the proxy (not the end client or server). There is no structured way for an end client or server to determine that a given proxy authenticated by SSL is a ``reasonable'' proxy for the desired end system. The degree to which this is an issue depends on the sensitivity of the information and the access control and authentication policies of the clients and servers involved. SSL does not provide any means for authenticating multiple parties along a transaction path.

* Performance impacts

There are several dimensions to performance including connection establishment latency, transaction overhead, and processing complexity. For SSL, the transaction overhead is not significant. The primary impact is on session establishment. Between 2 and 4 additional round trip times (beyond any other establishment) are required depending upon whether an SSL association has already been established (i.e. a master key exists) and whether client authentication is performed. In general, the operations performed by SSL are not expensive in terms of processing (symmetric key and hash operations vs. private key encryption operations).

SSL requires the maintenance of state information (keys, counters, identity, and algorithm information) by both the client and server. Management of this state information represents an additional requirement for the server.

* Granularity of security services provided by protocol

Security services are negotiated for an entire association and apply to the endpoints of the transport connection. In general, this implies a binding to an instance of an application process. The identity being authenticated will depend upon the naming information in the client or server certificate and on local key management issues (outside of the scope of the specification).

* Associated key management and cryptography

In SSLv2 the authenticated part of the key establishment is limited to RSA encryption of the secret key element. In v3, support for additional approaches including DH key exchange are included.

SSL reuses the same IV throughout an association. In general, this is not a problem given the frequency of changing session keys and the protection provided by the MAC.

* Negotiation of services, mechanisms, and formats

SSL negotiates algorithm information as part of association establishment. In SSLv2 the information used to negotiate algorithms is not authenticated. This allows an active attacker to cause two parties to use a particular selection common to both parties rather than having a user's own selection logic invoked. So long as both the client and server enforce a check that appropriate protection is applied to all information exchanged, this is not a major issue. It may result in weaker cryptographic protection being applied to an association than ``should'' have been used. In SSLv3, all negotiation exchanges are authenticated. There are very few options in SSLv2, consequently interoperability between independent implementations using common algorithm suites is likely.

* Ability to convey certificate and authorization information

SSL allows only the client or server certificate to be sent. No certification path, CRL, or authorization data can be exchanged. It is important that certificates used with SSL provide identification information which can meaningfully be compared with identity information used with HTTP.

* Compromise Recovery and Handling

No explicit mechanisms exist to clean up association data once established. This is an issue only if associations (i.e. master keys) exist for an extended period of time. Checks of certificate validity are performed only during association establishment.

* Susceptibility to active and passive attacks

The security services provided by SSL appear to be robust in the presence of active or passive attackers to the extent that robust cryptographic algorithms are selected.

* Time based issues

SSL does not rely on any clock based mechanisms for security services.

* Longevity of mechanism

SSL provides flexibility in algorithm selection and key management which provide for longevity of protection. There is a limit on the size of challenge information exchanged for association establishment, however the size seems more than adequate.

* Interoperability considerations

Some aspects of the SSL specification could be clearer in terms of the processing expected. Improved clarity would ease the development of interoperable implementations.

SSL's architectural placement make integration essentially transparent to applications (except with respect to exchange of security control information) and should simplify integration.

* Error handling and recovery

While an error reporting facility exists, there is little structure provided. Consequently, applications integrating with SSL may see slightly different behavior between different implementations with respect to error information returned. SSL is specified to abort a session in the event of an error.

next up previous
Next: 4.2 Security Assessment of Up: 4.1 Security Assessment of Previous: 4.1.2 Security Service Requirements
Denis Arnaud