Re: hamachi p2p vpn nat-friendly protocol details
Travis H. [EMAIL PROTECTED] writes: On 2/24/06, Alex Pankratov [EMAIL PROTECTED] wrote: Tero Kivinen wrote: Secondly I cannot find where it authenticates the crypto suite used at all (it is not included in the signature of the AUTH message). Crypto suite is essentially just a protocol number. It requires no authentication. If the server side responds with HELO.OK, it means that it can comprehend specified protocol revision. Similar to what happens during the SSH handshake. In SSL, the lack of authentication of the cryptosuite could be used to convince a v3 client that it is communicating with a v2 server, and the v3 server that it is communicating with a v2 client, causing them to communicate using SSL v2, which is called the version rollback attack. This isn't quite accurate. SSLv2 didn't do any kind of downgrade protection at all, for the version number, cipher suite, or anything else. SSLv3 used a MAC across the entire handshake. The tricky problem is to protect downgrade from SSLv3 to SSLv2, which obviously can't be done with the SSLv3 mechanisms. The trick that SSLv3 used was that when falling back to SSLv2, SSLv3-capable clients would pad their RSA PKCS#1 blocks in a special way that SSLv3 servers would detect. If they detected it, that meant there had been a downgrade. Unfortunately, not all clients correctly generate this padding and the check wasn't universally implemented correctly: http://www.openssl.org/news/secadv_20051011.txt -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: hamachi p2p vpn nat-friendly protocol details
I replied to Tero privately, then realized that I was not the only recipient of his email. So here's a copy for everyone's reference. Alex Tero Kivinen wrote: Travis H. writes: http://www.hamachi.cc/security Based on a cursory look over this, I'm impressed by both the level of detail and the level of security apparently afforded. Too bad I can't see the source code. I can see couple of problems in the system. Firstly it seems it uses same key for both directions for the encryption and for authentication, i.e. the KEYMAT is only split to Ke and Ka keys, which are used for encryption and authentication. In general using same keys for different directions is bad. The description on a page was not updated properly. Recent clients use per-direction keys after they complete P2P KE. Secondly I cannot find where it authenticates the crypto suite used at all (it is not included in the signature of the AUTH message). Crypto suite is essentially just a protocol number. It requires no authentication. If the server side responds with HELO.OK, it means that it can comprehend specified protocol revision. Similar to what happens during the SSH handshake. Also it seems that the identity itself is not authenticated at all, as it (or it's MACed form) is not included in the signature. It is not. There might be (I am not sure whether AUTH packet is encrypted and MACed) a MAC over it, but the MAC key is not yet authenticated as it is generated from the anonymous Diffie-Hellman. That might give it some protection, but I am not sure if that is enough. A protection against what kind of attack ? Identity is used to specify which public key the client wants to be authenticated with on the server side. Assuming it is swapped in transition by a man in the middle, it would still require an attacker to re-sign authentication hash in the message. Assuming he has a private key to do that, he will effectively succeed in authenticating under substituted ID. He then will need to re-sign server's auth hash to complete the attack, which is not going to happen. There is an off chance that the attacker might swapped the identity to one that has the same public key. The chances of this happening are infinitely small unless an attacker also has an access to victim's keypair, which becomes a trivial attack case. The protocol description is missing some details, so cannot say anything about them (things like what is the format of Ni, Nr, Gi, Gr when sent over wire and when put to the signatures etc, are the Gi, Gr always the lenght of modulus (2048 bits) etc). What would you like to know exactly ? The page was not meant to be a bit-level description of messages, merely a description of the security framework. The protocol is also tied to use SHA1. If you are referring to HMAC-SHA1 for authentication hashes, it is a part of a crypto suite (protocol revision) spec. In general it would be much better to use standard protocol, instead of generating your own. This is the second revision of Hamachi system. First revision was using SSL for cli-srv and IKE/ESP for p2p security. It was a prototype and it soon become obvious that both SSL and IKE were overkills for our purposes. We did not need certificate authentication of SSL, we did not want to run our own auth protocol over SSL/AnonDH, which would've increased the number of packets per login sequence. We didn't need the flexibility (ie complexity) of IKE either. After stripping down IKE (ie removing SA negotiation, reworking ID payloads and not doing quick mode), we essentially ended up with a protocol that was also fit for securing cli-srv session. It was further tweaked and replaced SSL. I should probably add that I implemented IKE (v1) keying daemon from scratch with all bells and wistles (NATT, extended MODP groups, etc) at some point in the past. Some remnants of it are still floating around, the library name was libike. Designing security protocols is hard... Yes, it is. This is why I like it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: hamachi p2p vpn nat-friendly protocol details
On 2/24/06, Alex Pankratov [EMAIL PROTECTED] wrote: Tero Kivinen wrote: Secondly I cannot find where it authenticates the crypto suite used at all (it is not included in the signature of the AUTH message). Crypto suite is essentially just a protocol number. It requires no authentication. If the server side responds with HELO.OK, it means that it can comprehend specified protocol revision. Similar to what happens during the SSH handshake. In SSL, the lack of authentication of the cryptosuite could be used to convince a v3 client that it is communicating with a v2 server, and the v3 server that it is communicating with a v2 client, causing them to communicate using SSL v2, which is called the version rollback attack. This is not relevant to the hamachi protocol because there is no negotiation. Nevertheless, authenticating the previous plaintext fields once a secure channel is established is considered good form. In Schneier's Practical Cryptography, he suggests computing the MAC over the entire history of sent messages, which ensures that any tampering is detected at the next MAC. This is eventually what was done in SSLv3, for reasons Tero alluded to and which are successfully thwarted for the reasons you describe. The protocol description is missing some details, so cannot say anything about them (things like what is the format of Ni, Nr, Gi, Gr when sent over wire and when put to the signatures etc, are the Gi, Gr always the lenght of modulus (2048 bits) etc). What would you like to know exactly ? The page was not meant to be a bit-level description of messages, merely a description of the security framework. Presumably he wants to make sure that the messages like the following have an unambiguous interpretation: AUTH Identity Signature(Ni | Nr | Gi | Gr, Kpri_cli) Merely concatenating them is insufficient unless all but one have a fixed length. I think a terse unambiguous representation rationale is the whole reason for ASN.1, although it seems awfully complex for such a simple goal. I sort of wonder at the utility of a TCP implementation of the p2p VPN... tunnelling TCP over TCP is well known to be a Bad Thing with regard to interaction of the TCP timeouts. Aside: Can anyone tell me why the constants used in ipad and opad for HMAC were chosen? If they're not arbitrary, I'd like to know the rationale behind them. -- Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: hamachi p2p vpn nat-friendly protocol details
Travis H. wrote: On 2/24/06, Alex Pankratov [EMAIL PROTECTED] wrote: Tero Kivinen wrote: [snip] The protocol description is missing some details, so cannot say anything about them (things like what is the format of Ni, Nr, Gi, Gr when sent over wire and when put to the signatures etc, are the Gi, Gr always the lenght of modulus (2048 bits) etc). What would you like to know exactly ? The page was not meant to be a bit-level description of messages, merely a description of the security framework. Presumably he wants to make sure that the messages like the following have an unambiguous interpretation: AUTH Identity Signature(Ni | Nr | Gi | Gr, Kpri_cli) Merely concatenating them is insufficient unless all but one have a fixed length. I think a terse unambiguous representation rationale is the whole reason for ASN.1, although it seems awfully complex for such a simple goal. Nonces and DH exponents are serialized using PER-style ASN.1 encoding. So the whole concatenation is unambigious. I sort of wonder at the utility of a TCP implementation of the p2p VPN... tunnelling TCP over TCP is well known to be a Bad Thing with regard to interaction of the TCP timeouts. Just to be clear, Hamachi tunnels VPN/P2P traffic over UDP. TCP is used for client-server session only. VPN over TCP is bad for two reasons. One you listed, and another is that it becomes trivial to DoS this kind of VPN. TCP packets are not authenticated (unless MD5/BGP extension is used, which is unlikely), so the state of VPN transport layer and consequently the state of a tunnel can be altered by 3rd party. That's why SSL VPNs make very little sense in non-proxied setups and that's why (I'd guess) OpenVPN 'tweaked' SSL to run over UDP instead. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
hamachi p2p vpn nat-friendly protocol details
http://www.hamachi.cc/security Based on a cursory look over this, I'm impressed by both the level of detail and the level of security apparently afforded. Too bad I can't see the source code. -- Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
