Better than nothing security: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Sandy Harris
No edit summary
m (Text replacement - "traffic analysis" to "traffic analysis")
 
(6 intermediate revisions by 3 users not shown)
Line 13: Line 13:
  | url = http://www.ietf.org/rfc/rfc5387.txt
  | url = http://www.ietf.org/rfc/rfc5387.txt
}}</ref>
}}</ref>
Setting up and managing a secure authentication infrastructure is not a trivial task and unauthenticated encryption does at least protect against all [[passive attack|passive eavesdropping]].
Setting up and managing a secure authentication infrastructure is by no means a trivial task and unauthenticated encryption does at least protect against all [[passive attack|passive eavesdropping]].


However, BTNS does not resist a [[man-in-the-middle attack]] because the underlying [[Diffie-Hellman]] protocol does not resist that unless authentication is used. The [[Internet Key Exchange]] (IKE) protocol is based on Diffie-Hellman; in normal IPsec usage it includes authentication and therefore does resists such attacks. BTNS does IKE without authenticaton and therefore cannot resist a man-in-the-middle attack.
However, BTNS does not resist a [[man-in-the-middle attack]] because the underlying [[Diffie-Hellman]] protocol does not resist that unless authentication is used. The [[Internet Key Exchange]] (IKE) protocol is based on Diffie-Hellman; in normal IPsec usage it includes authentication and therefore does resists such attacks. BTNS does IKE without authentication and therefore cannot resist a man-in-the-middle attack.


As the simplest example, consider someone who wants to access information that his employer or government frowns on. Assume all his packets pass through a firewall controlled by the adversary. If the threat he is concerned about is  is simple eavesdropping &mdash; reading the packet contents as they pass through the firewall &mdash; then either full IPsec or BTNS blocks that. If the threat is [[traffic analysis]], then neither BTNS nor full IPsec is of much help &mdash; the firewall can still see which server he is connecting to, and that may tell them all they need to know.
For example, consider someone who wants to access information that his employer or government frowns on. Assume all his packets pass through a firewall controlled by the adversary. If the threat he is concerned about is simple eavesdropping &mdash; reading the packet contents as they pass through the firewall &mdash; then either full IPsec or BTNS blocks that. The packets are all [[cryptography|encrypted]], so while the enemy can intercept them, he cannot read them unless he is remarkably good at [[cryptanalysis]]. If the threat is traffic analysis, then neither BTNS nor full IPsec is of much help &mdash; the firewall can still see which server he is connecting to, and that may tell them all they need to know. If the threat is some form of [[censorship]] or [[denial of service]], again neither BTNS nor full IPsec help much &mdash; the firewall can block them, just as it could block unencrypted traffic.


An [[active attack]]er can straightforwardly break BTNS with a technique that does not work against full IPsec. He builds a proxy program that runs on the firewall. It tells the user it is the server he wants to connect to and tells the server it is the user. This is the classic [[man-in-the-middle attack]]; the victims believe they are talking to each other, but actually both are talking to the enemy. IPsec includes authentication precisely to prevent this attack. Since BTNS does not use authentication, it is completely vulnerable to this.
The critical difference between the two systems is that an [[active attack]]er can straightforwardly break BTNS with a technique that does not work against full IPsec. He builds a proxy program that runs on the firewall. It tells the user it is the server he wants to connect to and tells the server it is the user. This is the classic [[man-in-the-middle attack]]; the victims believe they are talking to each other, but actually both are talking to the enemy. IPsec includes authentication precisely to prevent this attack. With full IPsec in play, neither the user's system nor the server will believe the proxy's lies because the proxy will not be able to authenticate correctly. However, since BTNS does not use authentication, it is completely vulnerable to this attack.


However, BTNS is still "better than nothing", and it is intended to be easy to set up and administer, so that it can easily be widely deployed.
However, BTNS is still "better than nothing", and it is intended to be easy to set up and administer, so that it can easily be widely deployed.


BTNS is even simpler than [[opportunistic encryption]], an earlier attempt at getting IPsec widely deployed with low administrative costs.
BTNS is even simpler than [[opportunistic encryption]], an earlier attempt at getting IPsec widely deployed with low administrative costs. One of the authors of the BTNS RFC, [[Michael Richardson]], also worked on [[FreeSWAN|FreeS/WAN]], the project that invented opportunistic encryption.


== References ==
== References ==
{{reflist}}
{{reflist}}

Latest revision as of 07:37, 22 June 2024

This article is a stub and thus not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

Better than nothing security, or BTNS, is basically IPsec done without authentication.[1][2] Setting up and managing a secure authentication infrastructure is by no means a trivial task and unauthenticated encryption does at least protect against all passive eavesdropping.

However, BTNS does not resist a man-in-the-middle attack because the underlying Diffie-Hellman protocol does not resist that unless authentication is used. The Internet Key Exchange (IKE) protocol is based on Diffie-Hellman; in normal IPsec usage it includes authentication and therefore does resists such attacks. BTNS does IKE without authentication and therefore cannot resist a man-in-the-middle attack.

For example, consider someone who wants to access information that his employer or government frowns on. Assume all his packets pass through a firewall controlled by the adversary. If the threat he is concerned about is simple eavesdropping — reading the packet contents as they pass through the firewall — then either full IPsec or BTNS blocks that. The packets are all encrypted, so while the enemy can intercept them, he cannot read them unless he is remarkably good at cryptanalysis. If the threat is traffic analysis, then neither BTNS nor full IPsec is of much help — the firewall can still see which server he is connecting to, and that may tell them all they need to know. If the threat is some form of censorship or denial of service, again neither BTNS nor full IPsec help much — the firewall can block them, just as it could block unencrypted traffic.

The critical difference between the two systems is that an active attacker can straightforwardly break BTNS with a technique that does not work against full IPsec. He builds a proxy program that runs on the firewall. It tells the user it is the server he wants to connect to and tells the server it is the user. This is the classic man-in-the-middle attack; the victims believe they are talking to each other, but actually both are talking to the enemy. IPsec includes authentication precisely to prevent this attack. With full IPsec in play, neither the user's system nor the server will believe the proxy's lies because the proxy will not be able to authenticate correctly. However, since BTNS does not use authentication, it is completely vulnerable to this attack.

However, BTNS is still "better than nothing", and it is intended to be easy to set up and administer, so that it can easily be widely deployed.

BTNS is even simpler than opportunistic encryption, an earlier attempt at getting IPsec widely deployed with low administrative costs. One of the authors of the BTNS RFC, Michael Richardson, also worked on FreeS/WAN, the project that invented opportunistic encryption.

References

  1. N. Williams, M. Richardson, ed. (November 2008), Better-Than-Nothing Security: An Unauthenticated Mode of IPsec, RFC5386
  2. J. Touch, D. Black & Y. Wang, ed. (November 2008), Problem and Applicability Statement for Better-Than-Nothing Security (BTNS), RFC5387