[Pkg-openssl-devel] Bug#694667: Bug#694667: Partial solution for OpenSSL 1.0.1 bugs #665452, #666051, #2771

[Kurt Roeckx]

Hi,

The problem with Path MTU Discovery is that if nobody gives an
error that the packet should be smaller, it will keep re-transmitting
the IP packet with the same size, and will not split it up.  The
other side will not see any of your data.  The connection will
work until you send this big data packet and will then just hang.

The application that hangs will also not notice that, it will just
assume that the other didn't reply.

Broken Path MTU Discovery problems are really annoying, because
most people don't even know what is going on.  But you should see
that netstat still reports a send queue, and if you watch the
network traffic with wireshark or something you should see that
the same packet is being re-transmitted.

There is nothing SSL can do about this, since this is above the
TCP layer, and it's the TCP layer that's having a problem.

At least from your description, I think that that is your problem,
and if you don't think that's the case I'll need more information.


Kurt

On Mon, Dec 17, 2012 at 10:55:34AM -0700, Zack Morris wrote:
> Hey sorry for my late reply, this email got caught in a spam black hole.
> ICMP does work, I'm able to ping and traceroute and all that.  I guess I
> don't understand how the relationship  between path MTU detection and
> SSL works.  In my mind, SSL would work at stream level (regardless of
> how the packets get swizzled in the wild).  It would handle security
> purely cryptographically and not worry about weaker MITM attacks where
> something about the packet (length/headers/what have you) doesn't match.
> 
> I guess another way of saying that is, we should assume that all packets
> are being watched and chopped up in various ways, and SSL should still
> function properly because the data is mathematically inaccessible even
> by brute force.  Otherwise I worry that someone could spoof MTU issues
> somehow and prevent someone from opening an SSL connection.
> 
> I could maybe see how weak MITM attack sensing might be useful for
> self-signed certificates to cut down on attacks in practice (while
> prototyping a webserver on linode etc).  But honestly I don't even think
> it should even be turned on for real security applications because then
> it's just putting another hurdle up that adds no strong security
> benefit.  I lost about 8-16 hours of work tracking this down because I'm
> not a network administrator.
> 
> So on that note, a quick fix would be to report an error in verbose mode
> with the MTU is too low (I mean simple enough that web developers using
> curl can see it) and then decide if you want to skip the checking down
> the road.
> 
> Thanks,
> 
> Zack Morris
> 
> -----Original Message-----
> From: Kurt Roeckx [mailto:kurt at roeckx.be] 
> Sent: Wednesday, November 28, 2012 2:35 PM
> To: Zack Morris; 694667 at bugs.debian.org
> Subject: Re: [Pkg-openssl-devel] Bug#694667: Partial solution for
> OpenSSL 1.0.1 bugs #665452, #666051, #2771
> 
> On Wed, Nov 28, 2012 at 02:15:05PM -0700, Zack Morris wrote:
> > 
> > sudo ifconfig eth0 mtu 1496
> > 
> > The issue seems to be caused by something with TLS hanging with 
> > fragmented packets.  Our network's MTU is 1496 instead of 1500.  The 
> > server would wait after the client sent the initial client hello 
> > message.  I tried everything from upgrading to 1.0.1-4ubuntu5.5 to 
> > passing CAfile and -cipher with no luck.  I am using Ubuntu 12.0.4 
> > linux 3.2.0-24-generic.
> 
> This issue you're having seems to me totally unrelated to openssl, just
> that for the host you're connecting to Path MTU Detection doesn't work
> properly.  That's becauase some people filter too much icmp traffic.
> 
> If there is something in your network that limits it to 1496, I suggest
> you set your mtu like that.  This will avoid many problems.
> 
> ping with "-s 30000" should also work if nothing gets filtered.
> 
> A tool to diagnose those PMTUD problems is tracepath.
> 
> 
> Kurt
>