lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 11 Jun 2013 09:43:07 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Pablo Neira Ayuso" <pablo@...filter.org>,
	<netfilter-devel@...r.kernel.org>
Cc:	<davem@...emloft.net>, <netdev@...r.kernel.org>
Subject: RE: [PATCH 3/5] netfilter: xt_TCPMSS: Fix violation of RFC879 in absence of MSS option

> The clamp-mss-to-pmtu option of the xt_TCPMSS target can cause issues
> connecting to websites if there was no MSS option present in the
> original SYN packet from the client. In these cases, it may add a
> MSS higher than the default specified in RFC879. Fix this by never
> setting a value > 536 if no MSS option was specified by the client.
> 
> This closes netfilter's bugzilla #662.
...
> +	/* RFC 879 states that the default MSS is 536 without specific
> +	 * knowledge that the destination host is prepared to accept larger.
> +	 * Since no MSS was provided, we MUST NOT set a value > 536.
> +	 */
> +	newmss = min(newmss, (u16)536);
> +

Is setting the mss to 536 actually ever sensible?
RFC 879 might say that it is the default (and the minimum
that must be supported), but in practise the actual mss
is very likely to be only slightly shorter than the standard
ethernet mss.
Although strict conformance with RFC 879 might require the mss
be clamped to 536, pragmatically a value much nearer 1400 would
make sense - systems with very low mtu/mss are probably likely
to advertise it.

	David



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ