Message-ID: <4ef5fec60602271326k46e2f50al5324482d8dc2181f@mail.gmail.com>
Date: Mon Feb 27 21:27:08 2006
From: coderman at gmail.com (coderman)
Subject: Fwd: hamachi p2p vpn nat-friendly protocol details

last forward for now. (my apologies to the annoyed)

so what say ye, full-disclosure?  the cypherpunk mission more relevant
than ever yet the birthplace remains a barely animated near-corpse...

---------- Forwarded message ----------
From: coderman <coderman@...il.com>
Date: Feb 27, 2006 11:56 AM
Subject: hamachi p2p vpn nat-friendly protocol details
To: cypherpunks@...t.org, "Peer-to-peer development." <p2p-hackers@....org>


--- various interesting forwards related to decentralized (p2p)
authenticity and privacy

favorite quote:
">> Designing security protocols is hard...

Yes, it is. This is why I like it."

---

'Cypherpunks Write [Secure] Code!'

An open question for anyone reading this:

is the critically wounded, barely beating cypherpunks list languishing
in such a sad state due to apathy or impending irrelevance/death?  i
see embers of life awaiting some minimal votes of confidence (i'd go
so far as to offer sexual favors for a toad node back* :) but any kind
of renewed interest is meager at best.  [would a public list archive
help? an rss feed? a abridged list / digest? [ala kernel trap]]

such volatile times, so little interest...

----

http://www.mail-archive.com/cryptography@metzdowd.com/msg05790.html

""
Alex Pankratov
Sun, 26 Feb 2006 07:18:15 -0800
...
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 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.
""


=====

http://www.mail-archive.com/cryptography@metzdowd.com/msg05796.html

Travis H.
Sun, 26 Feb 2006 07:22:06 -0800

> 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.
.
.
.
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.


=====

http://www.mail-archive.com/cryptography@metzdowd.com/msg05801.html

Alex Pankratov
Sun, 26 Feb 2006 07:24:20 -0800

> 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.

---end-cut---

Powered by blists - more mailing lists