Difference between revisions of "Key exchange without entity authentication"

From OWASP
Jump to: navigation, search
(Fixed the category.)
(Related Attacks)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 +
{{Template:Vulnerability}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
Performing a key exchange without verifying the identity of the entity being communicated with will preserve the integrity of the information sent between the two entities; this will not, however, guarantee the identity of end entity.
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
==Consequences ==
+
==Description==
  
* Authentication: No authentication takes place in this process, bypassing an assumed protection of encryption
+
Performing a key exchange without verifying the identity of the entity being communicated with will preserve the integrity of the information sent between the two entities; this will not, however, guarantee the identity of end entity.
  
* Confidentiality: The encrypted communication between a user and a trusted host may be subject to a "man-in-the-middle" sniffing attack
+
'''Consequences'''
  
==Exposure period ==
+
* Authentication: No authentication takes place in this process, bypassing an assumed protection of encryption
 +
* Confidentiality: The encrypted communication between a user and a trusted host may be subject to a "man-in-the-middle" sniffing attack
  
* Design: Proper authentication should be included in the system design.
+
'''Exposure period'''
  
* Design: Use a language which provides an interface to safely handle this exchange.
+
* Design: Proper authentication should be included in the system design.
 +
* Design: Use a language which provides an interface to safely handle this exchange.
 +
* Implementation: If use of SSL (or similar) is simply mandated by design and requirements, it is the implementor's job to properly use the API and all its protections.
  
* Implementation: If use of SSL (or similar) is simply mandated by design and requirements, it is the implementor's job to properly use the API and all its protections.
+
'''Platform'''
  
==Platform ==
+
* Languages: Any language which does not provide a framework for key exchange.
 +
* Operating platforms: All
  
* Languages: Any language which does not provide a framework for key exchange.
+
'''Required resources'''
 
+
* Operating platforms: All
+
 
+
==Required resources ==
+
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
High
 
High
  
==Avoidance and mitigation ==
+
Key exchange without entity authentication may lead to a set of attacks known as "man-in-the-middle" attacks. These attacks take place through the impersonation of a trusted server by a malicious server. If the user skips or ignores the failure of authentication, the server may request authentication information from the user and then use this information with the true server to either sniff the legitimate traffic between the user and host or simply to log in manually with the user's credentials.
  
* Design: Ensure that proper authentication is included in the system design.
 
  
* Implementation: Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.
+
==Risk Factors==
  
==Discussion ==
+
TBD
  
Key exchange without entity authentication may lead to a set of attacks known as "man-in-the-middle" attacks. These attacks take place through the impersonation of a trusted server by a malicious server. If the user skips or ignores the failure of authentication, the server may request authentication information from the user and then use this information with the true server to either sniff the legitimate traffic between the user and host or simply to log in manually with the user's credentials.
+
==Examples==
 
+
==Examples ==
+
  
 
Many systems have used Diffie-Hellman key exchange without authenticating the entities exchanging keys, leading to man-in-the-middle attacks. Many people using SSL/TLS skip the authentication (often unknowingly).
 
Many systems have used Diffie-Hellman key exchange without authenticating the entities exchanging keys, leading to man-in-the-middle attacks. Many people using SSL/TLS skip the authentication (often unknowingly).
  
==Related problems ==
+
==Related [[Attacks]]==
  
* [[Failure to follow chain of trust in certificate validation]]
+
* [[Man-in-the-middle attack]]
  
* [[Failure to validate host-specific certificate data]]
+
==Related [[Vulnerabilities]]==
  
* [[Failure to validate certificate expiration]]
+
* [[Failure to follow chain of trust in certificate validation]]
 +
* [[Failure to validate host-specific certificate data]]
 +
* [[Failure to validate certificate expiration]]
 +
* [[Failure to check for certificate revocation]]
  
* [[Failure to check for certificate revocation]]
+
==Related [[Controls]]==
  
 +
* Design: Ensure that proper authentication is included in the system design.
 +
* Implementation: Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.
  
[[Category:Vulnerability]]
 
  
[[Category:Protocol Errors]]
+
==Related [[Technical Impacts]]==
  
[[Category:OWASP_CLASP_Project]]
+
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
  
[[Category:Cryptographic Error]]
+
 
 +
==References==
 +
TBD
 +
 
 +
 
 +
__NOTOC__
 +
 
 +
 
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Vulnerability]]
 +
[[Category:Protocol Errors]]
 +
[[Category:OWASP_CLASP_Project]]
 +
[[Category:Cryptographic Vulnerability]]
 +
[[Category:Vulnerability]]

Latest revision as of 09:31, 26 February 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


Last revision (mm/dd/yy): 02/26/2009

Vulnerabilities Table of Contents

Description

Performing a key exchange without verifying the identity of the entity being communicated with will preserve the integrity of the information sent between the two entities; this will not, however, guarantee the identity of end entity.

Consequences

  • Authentication: No authentication takes place in this process, bypassing an assumed protection of encryption
  • Confidentiality: The encrypted communication between a user and a trusted host may be subject to a "man-in-the-middle" sniffing attack

Exposure period

  • Design: Proper authentication should be included in the system design.
  • Design: Use a language which provides an interface to safely handle this exchange.
  • Implementation: If use of SSL (or similar) is simply mandated by design and requirements, it is the implementor's job to properly use the API and all its protections.

Platform

  • Languages: Any language which does not provide a framework for key exchange.
  • Operating platforms: All

Required resources

Any

Severity

High

Likelihood of exploit

High

Key exchange without entity authentication may lead to a set of attacks known as "man-in-the-middle" attacks. These attacks take place through the impersonation of a trusted server by a malicious server. If the user skips or ignores the failure of authentication, the server may request authentication information from the user and then use this information with the true server to either sniff the legitimate traffic between the user and host or simply to log in manually with the user's credentials.


Risk Factors

TBD

Examples

Many systems have used Diffie-Hellman key exchange without authenticating the entities exchanging keys, leading to man-in-the-middle attacks. Many people using SSL/TLS skip the authentication (often unknowingly).

Related Attacks

Related Vulnerabilities

Related Controls

  • Design: Ensure that proper authentication is included in the system design.
  • Implementation: Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.


Related Technical Impacts


References

TBD