|
|
On Wed, 11 May 2005 chosner@xxxxxxxxxxxxxxxxx wrote: > Like Rick says, OpenVPN uses an "ESP in Tunnel mode LIKE" structure. I'm > pretty sure it's not a problem since integrity control is applied at the > same level as confidentiality control, resulting in errors in one or both > being easier to couple together by the security control. IPSec ESP in > Tunnel mode without integrity uncouples these two, allowing confidentialy > to happen at a lower OSI layer, and relying on a higher layer, post > decryption, to handle integrity. I think that is the crux of the problem. > OpenVPN is doing both in a coupled fashion at the same layer making it > harder to use one control to fool the other. I would like to hear from > others who can confirm my assessment, or explain it better. I'd sum it up > at "don't decrypt your data at layer 2, then hand it up to layer 4-7 for > integrity checking, and if you do, don't return error messages with > anything other than generic data in them." > > Perhaps another potential weakness of protocol/kernel coupling and the > danger of using complex protocols for security controls. While it's true that OpenVPN's tunnel security layer (after the TLS handshake has established symmetrical session keys) is closely modeled on IPSec ESP, OpenVPN applies an HMAC-SHA1 integrity check to all tunnel packets AFTER encryption, and the receiver checks the HMAC-SHA1 signature BEFORE decryption. This design is explicitly intended to prevent an attacker from being able to pass ciphertext of their own choosing into the receiver's decryption algorithm. So in the language of IPSec, OpenVPN implements the equivalent of Encapsulating Security Payload (ESP) in tunnel mode with confidentiality and integrity protection being provided at the same protocol level. In a way, I'm surprised this is news, as when I was initially designing the OpenVPN security model 3 years ago, all the research at that time indicated that "Encrypt then MAC" was a stronger approach than "MAC then encrypt", because the former prevents an attacker from injecting arbitrary ciphertext into the receiver's decryption algorithm. Actually, taking a second look at the paper, it looks like they've taken the "well-known bit flipping weakness of CBC mode encryption" which has been known for years, and are trying to show how it could be practically exploited when ESP-level integrity protection is turned off. James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |