Introduction l l SSL Is used to

: Introduction l l SSL Is used to carry application layer protocols in a secure way. Carrying an application data over an SSL connection at a naive way can lead to reduction in security and performance. In order to design well we have to know the security capabilities of SSL.

First thing: Know what you want to secure. Evaluate a ‘Threat model’ for the application you want to secure. l Figure out what are the vulnerabilities of the system you are trying to secure (taking the costs into consideration). l Check what are the security services your application needs: 1. Confidentiality (not always needed). 2. Message integrity (a must). 3. endpoint authentication (highly recommended). It’s not necessary that all security services be provided by SSL. l

Next step: Identify which security services are best provided by SSL and which by the application. l l l Confidentiality. Message integrity (should be done by SSL). Endpoint authentication: l l Server authentication (better with SSL). Client authentication (optional in SSL). Rule of Thumb: l Message integrity isn’t optional-always provide it. l It is best to provide confidentiality (for interoperability with other SSL implementations and for answering the users expectations). l Avoid client authentication unless you really need it.

Client authentication options: The ideal situation – giving a certificate for each client we want to authenticate. Since it presents deployment problems we need other options: 1. Username/password authentication: 2. Username/ password variants authentication.

Username/password authentication This is the most traditional way to do client auth. It’s usually combined with “ Access control list” (ACL). Disadvantages: l Vulnerable to simple passive attacks (like sniffing attack) – can be prevented by SSL. l Vulnerable to the following three major types of attacks: 1. man-in-the-middle attack (if the client doesn’t check the server’s certificate). 2. Password guessing attack – people tend to choose easy passwords. Countermeasures against password guessing: limited tries, slowing down each password check.

3. Passwords are transferable-if the user chooses the same password on multiple machines, the server can impersonate him to another server. Conclusion: Although passwords are better over SSL, they still have substantial weaknesses.

Username/password variant authentication: Since many systems uses the username/password model, more complicated methods were designed to improve the security of this model. For example: One time password (OTP) methods such as ‘secure. ID’ cards. These methods prevents attacks on the connection carrying the password. Since SSL prevents these attacks-It is useful only in system with both insecure and secure connections.

SSL client authentication: Client authentication In SSL is certificate-based. Advantages of using SSL client auth. : l Doesn’t have any of the weaknesses of password-based authentication Much more secure.

Disadvantages of using SSL client auth. : l Operational problem (arrangement with CA’s, user list for maintenance). l Vast majority of clients can not access the server – undesirable for a business. l l Needs mapping certificates to user identities (ACLs entries should be the same as the identities in the certificates). Certain attacks are still possible – like tricking the client to make auth. request for the attacker.

Rule of thumb: l In most cases, it’s easier to offer the clients a username/password authentication. l Passwords are easier to integrate with most systems and the users understand them better. l For automated clients (such as web servers) its just as easy to manage with certificates.

SSL client authentication cont. Three major subjects should be taken into consideration when using SSL client authentication: 1. Certificate issuance: The two primary problems: A. Correctly authenticate users before issuing them certificates. Solutions: 1. seeing the user’s physical identity and then issuing him the certificate. 2. Issuing on-line by asking identity marks (credit card number, etc. )

B. Arranging that only one user can get a certificate with a certain username. Solution: Issue temporary password through some external mechanism.

2. Access control: Enable us to provide different levels of access to different classes of users (using certificates too). l can be done by access control lists (ACLs). Advantages of this approach: 1. Permissions can be changed by merely changing ACLs (no issuing of new certificate). 2. We can have a mixed system with both certificates and passwords (by having a function that does the mapping). l

Alice’s certificate Bob’s certificate User List User Alice Bob Charlie Password . . ………. . Access control list User Alice Bob Charlie Action Permit Deny Permit ……………. .

Disadvantages: l l Requires user data to be maintained in two locations: The ACL and the CA. (Makes it more problematic to create user). The ACL and CA can get out of synch.

3. Removing users: When using ACLs – merely remove the access control list. When not using ACLs – use certificate revocation Lists (CRLs). Harder since CRLs lacks a direct support in SSL.

Host to host connection: This is a case where certificate-base authentication Can be used with minimal overhead. Secure tunnel In this case all we care about is identity on the other end Thus we can do client auth. the same as server auth. (No need for ACLs and clients removal).

Server authentication: Server authentication is done by checking the reference integrity. Server identity: Ensuring a secure connection with SSL requires verifying the server identity (to prevent man-in-the middle attack). Two things are required: 1. Verifying the server’s certificate. 2. Verifying that the server is indeed the server you’re expecting to talk to. In some cases, SSL allows for the server to remain anonymous (by SSL_DH_anon cipher suites) but these suites are completely vulnerable to an active attack. (its better if combined with passwords).

Security properties: The client needs to verify that the level of secure of the connection meets his expectations. Two examples of ways to verify the security level: 1. Telnet protocol: The client may simply have the domain name of the server. 2. HTTP protocol: the client has an indication in the URL that the protocol should be over SSL. (The URL begins with “ https: \ ”). Remark: the enforcement of secure connections must generally be done on the client side.

Rule of thumb: We need to provide a reference that: 1. Concretely identifies the server that the client can expect to connect to. 2. Indicate that SSL is required. The server identity needs to be able to automatically Compared to the server’s certificates (via domain name).

SSL limitations. Cases where we should not use SSL: 1. No repudiation: SSL can not be use to provide no repudiation of data. For example: an online purchase. SSL insures that : 1. You are talking to the correct server. 2. The receipt you were given hasn’t been tampered with. But since the content of the receipt can’t be externally verified The merchant can claim that you forged the receipt.

2. End-To-End security: SSL is bad in cases where our machine is behind a firewall Machine A Machine B

Protocol selection. We have to be able to know if a connection carrying a secure version of a protocol or an insecure one. Requirements for parallel secure and insecure operations: 1. We must be able to unambiguously distinguish secure and insecure connections. 2. Clients who are unaware to security issues must be able to operate with security aware clientsservers. Two common approaches to protocol selection: 1. Separate ports. 2. Upward negotiation.

Separate ports. We assign different ports for the secure and the insecure versions of the protocol. Disadvantages: l There is a limited number of ports (around 65000). l The client has to know to use SSL and to move to the secure port. l Requires modification to some firewalls which don’t allow TCP connections except on specific ports.

Advantages: l l l The implementation is trivial (arranging the server to listen to both ports). Doesn’t require any real modification to the application-layer protocol. Secure and insecure implementation never interact at all.

Downgrade attacks on separate ports: For The attacker make it appear that the server isn’t instance, amazon. com’s web server contains the Following text: on the appropriate port at all. listening Client Attacker Server “If you received an error message when you tried to use TCP Syn our secure server, sign in using our standard server. If You select. RST packet the secure server, the information you enter Will be encrypted”. The client can make this attack worse If he moves to insecure mode.

2. Upward negotiation. In this strategy one side will indicate that he supports SSL and the other side will indicate that he wants it. The SSL handshake will occur The rest of the protocol will run over the secured Connection.

Upward negotiation Client server Hello (SSL Supported) Hello (Start SSL) Client hello Rest of SSL Handshake First application protocol message

Advantages of upward negotiation: Doesn’t require allocating an extra port. l Automatic discovery – the client doesn’t need to know that security is available. Disadvantages: l Requires substantial modifications to the code on both server and client (support must be added in order to negotiate). l Need to define what to do when the handshake is failed (reconnect insecurely, signal an error etc. ). l Has a performance cost (need to first check that the SSL is permitted). l Requires change to the code of the firewall proxies so they could recognize the upward negotiation and get out of the way. l

Downgrade attacks on upward negotiation. Attacker Client Hello(SSL s upported ppo o(SSL Not su Hell First application protocol messag e server Hello(SSL No t supported Not suppor Hello(SSL First application Protocol message

Countermeasures: Rule of thumb: 1. It’s much easierservers with whom we had a 1. Remember to design and implement a separate 2. port strategy. secure connection and insist on secure 3. 2. When designing a protocol for largely internal connections with them. usage 2. References to servers must indicate that the 4. use separate ports. site is secure and what sort of negotiation is 5. 3. When designing for broad standardization its available. worth users must be upgrade to make insecure 6. 3. paying the cost oftaught notnegotiation strategy. connections when secure connections fails.

Rehandshake Useful in the following cases: l l The server demands that different types of protocol request will require different levels of security. Client authentication is required (by the server before providing it any restricted services). Cipher suite upgrading. Replenishment of keying material (to prevent large-scale attack on long lived connections).

Case Generate Error closure Resume session SSL provides its one closure mechanism: the close_notify alert Incomplete close (to prevent forging the TC Fins). No Yes Incomplete close: When the implementation send a close_notify and immediately close the connection. Premature close No No Premature close: after End of Data Here, one side closes the TCP connection (i. e. sends a Fin) without first sending a close_notify. Premature close Yes No w/o End Of Data Security threat (the FIN segment could be forged).

summary. l l l l Not all security services need to be provided via SSL. Both protocol selection mechanisms have values. Authenticate servers with certificates. Set client security expectations. Certificates are harder than passwords, but also stronger. Define rehandshake semantics. Closure is tricky.