DSD SECURITY POLICY ADVISORY ON THE USE OF SSL Version 1.0 7 June 2001 BACKGROUND Use of the Internet has given rise to an increasing demand to use Secure Sockets Layer (SSL) as a security protocol. If implemented properly, it allows client/server applications to communicate in a secure manner, avoiding risks such as eavesdropping and tampering. SSL is a popular component in the design of 'e-commerce' sites because it is supported by all the common web browsers. SSL is capable of providing both encryption and authentication. It is however not a cryptographic algorithm rather it can implement a range of symmetric and asymmetric algorithms including 3DES (triple DES), SHA-1, and RSA. Current Government policy directs Government organisations to only use cryptographic products approved by DSD. The configuration options and implementation opportunities for SSL are wide and varied, and there are some standard implementations that the Information Security Group of DSD will not endorse. This Policy Advisory provides guidance on appropriate use of SSL, but it should be noted carefully that SSL is simply one component of the complete security architecture for any Internet service. It is important to be mindful of all vulnerabilities in an Internet service, and also to recognise that the range of threats to an Internet service are likely to change over time. SCOPE DSD has not formally evaluated the implementation of each cryptographic algorithm in any of the common web browsers and servers that implement SSL. There is a small possibility that one or more of these software products contains software bugs. Consequently the information in this Policy Advisory should only be applied in circumstances where this possibility is taken into account with considered discretion. SSL is typically used to safeguard sensitive data that is UNCLASSIFIED but requires protection. A large proportion of Government e-business lies in this category. Some well-considered risk justification is necessary when choosing unevaluated SSL for systems at the IN-CONFIDENCE level. It should be noted that there are other systems (for example Fedlink) and products on the Evaluated Products List (EPL) that provide greater security assurance. These options should always be investigated first when designing systems. For protection during transit over the Internet of Government data classified at PROTECTED or above SSL is not appropriate. Within a PROTECTED environment SSL may be considered for the protection of HIGHLY PROTECTED data during transmission. However, it should be recognised that SSL does not protect the data during storage. Furthermore, options on the EPL should be considered in the first instance. SSL must not be used to safeguard the transmission over the Internet of information with a National Security classification. It is also not appropriate to use SSL for the protection of information classified as CABINET-IN-CONFIDENCE. USING SSL Using SSL as a confidentiality tool to encrypt transactions will provide reasonable security against unauthorised interception of information during transit, provided that the encryption key is appropriately protected. For most applications the possibility of interception is unlikely to be the most significant area of risk. There is usually substantially greater risk that the information can be accessed whilst stored on a server, at either end of the transaction link, where SSL will not protect it. As a confidentiality tool SSL is suitable for use in common transactions involving (for example) credit cards, personal information, and username/password challenges. SSL also supports authentication mechanisms that can assist users to identify transaction endpoints with some confidence. To be effective these mechanisms must be supported by a combination of appropriate private key protection, user willingness and ability to validate identity certificates, and the use of a legitimate identity registration scheme. It can be difficult or expensive to sustain these three supporting elements, and prospective developers should be mindful that the strength of an authentication mechanism might be flawed if it is inadequately supported. Similarly, users should be mindful that authentication mechanisms implemented via SSL are not foolproof. RECOMMENDATIONS FOR MAXIMISING SSL CRYPTOGRAPHIC SECURITY SSL servers and clients can be configured to use only specific cryptographic algorithms. At the start of an SSL session the server process will negotiate with the client process and select the 'strongest' cryptographic algorithm that can be used by both processes. However, if the server and client have each been configured so that there is no common algorithm, the server can refuse to connect. This can be a useful feature because it allows the server to set a minimum acceptable standard for the cryptographic algorithm(s) to be used in each session. If an application has been installed without any attention paid to the SSL configuration, it is possible that relatively weak cryptographic algorithms will be chosen without the user being aware. This is the most common problem seen with the use of SSL. It is strongly recommended that SSL be explicitly configured in application server software. If the vendor has correctly implemented the cryptography, then the following choices will maximise the security of SSL sessions: - Only allow SSL version 3.0 sessions. - Disable reversion to SSL version 2.0. - The key exchange algorithm should be RSA with a key length of at least 1024 bits. - The cryptographic algorithms selected for the sessions should be one or more of the following : - Triple-DES in CBC mode, 168-bit session key, SHA MAC - Triple-DES in CBC mode, 168-bit session key, MD5 MAC - RC4, 128-bit key, SHA MAC - RC4, 128-bit key, MD5 MAC Information Security Group staff can assist you if an explanation of these parameters and acronyms is required. FURTHER ADVICE Please consult with the Information Security Group at DSD if you need further advice on the use of SSL in any application. The Group may be contacted via - Email assist@dsd.gov.au Post Information Security Group Defence Signals Directorate Locked Bag 5076 Kingston ACT 2604