SSL / SSH and MTU Problems

A colleague of mine recently encountered mysterious issues with SSL connections that dropped large numbers of packets, while cleartext pages loaded fine.  After a bit of digging, he found that decreasing his DSL router’s MTU size from 1410 to 1400 seemed to do the trick.

I did some looking around, and found this page from Primus Telecom (Australia) that describes the problem well.

When you access a website or essentially do anything on the Internet, your computer places the information into packets, the size of which is determined by the MTU (Maximum Transmission Unit). On an Ethernet network the default MTU size is 1500 bytes, which is what most routers on the Internet will accept, the problem however occurs when we introduce protocol overheads.

Because there are a number of different protocols your data packets may be encapsulated into, the size of the MTU can increase at different places in the network. If the packet is already close to 1500 bytes when it leaves your ADSL router, it may become larger than 1500 by the time it gets to its destination, which means it will be fragmented, or split up.

Encryption protocols generally can’t handle packet fragmentation, though this is more by design, rather than as a fault, as fragmentation may introduce a point of insecurity, and allow the encryption to be broken or intercepted.

The overhead mentioned consists of datagram encapsulation, for example, and is added by routers along the way.

When using SSL / SSH, the sending machine will set the IP “do not fragment” (DF) header bit to “1″.  Ideally, traffic is sent via the largest size that does not fragment; RFC 1191 describes a technique to use the DF header to discover the PMTU (path MTU, this maximum size.)  Lowering it on first hop after your sending machine will do the trick, though.