Displaying 4 results from an estimated 4 matches for "md5sig".
Did you mean:
md5s
2016 Jan 15
3
[Patch] TCP MD5SIG for OpenSSH
On 15 January 2016 at 08:48, Alex Bligh <alex at alex.org.uk> wrote:
> > The socket option is enabled *after* connection establishment, thus
> > doesn't protect against SYN floods. This is because server doesn't
> > know (in userspace) what the address of the peer is until they
> > connect. Again because signed addresses.
> So could they exchange a secret
2016 Jan 15
2
[Patch] TCP MD5SIG for OpenSSH
...igh <alex at alex.org.uk> wrote:
[snip]
> 3. Server compares supplied address/port pair with what it sees
> (to detect DNAT like Amazon elastic IPs), and if they are the
> same, it waits for the TCP ECHO reply, and if it gets it
> says "Excellent, let's apply TCP-MD5SIG, here is a
> random key", and from that point on TCP-MD5SIG is applied
> both times, else proceeds as normal.
>
> I don't see the advantage in hashing a session key (which should
> be kept private) over using a random key. The random key could
> be hashed with the s...
2016 Jan 15
0
[Patch] TCP MD5SIG for OpenSSH
On 15 Jan 2016, at 16:27, Roland Mainz <roland.mainz at nrubsig.org> wrote:
> Don't these extra roundtrips further increase the latency of ssh
> connection setup (e.g. imagine a high-bandwidth&&high-latency satelite
> link) ? ssh is already a *PAIN* in that area, killing it's usefullness
> for applications like "Distributed make" because the time to
2016 Jan 14
5
[Patch] TCP MD5SIG for OpenSSH
The intent of this option is similar to "tls-auth" in openvpn[1]: To
refuse to talk to anyone who doesn't know the shared secret.
You could compare this to port knocking, in that it solves a similar
problem.
This also prevents RST attacks from killing an existing connection,
even when attacker can sniff sequence numbers.
This feature doesn't work through NAT, since the source