Issue in ssl negociation

[Maxim Dounin]

Hello!

On Wed, Dec 07, 2011 at 05:33:14AM -0500, brunoa wrote:

> Hello,
> 
> This is my first POST, so please forgive me if I used the wrong
> mailing-list...
> 
> I am using nginx v0.7.65 on Debian squeeze. I have a sporadic issue
> occuring on requests coming from Android mobile phones, concerning ssl
> negociation.
> 
> After receiving "Client Hello" from the phone, nginx sends 2 packets:
> "Server Hello" and a 1st fragment on the "Certificate, Server Hello
> Done" (line 7 in the trace below). Then, it waits for the Ack of the
> "Server hello" and never sends the 2nd fragment of the "Certificate,
> Server Hello Done". It retransmitts the "Server Hello", but the client
> is stuck waiting for the second fragment of the certificate.
> 
> And the Android device, I have a 1minute timeout which expires and
> throws the error "no peer certificate" (see the FIN,Ack, line 12).
> 
> Immediately after, nginx sends the second fragment of the "Certificate,
> Server Hello Done" message (line 13).
> 
> My questions are: is nginx fragmenting packets on purpose ? Is there a
> way to disable this and let IP layer do the fragmentation ?

nginx not fragmenting anything, it's tcp/ip which do this.

> Could upgrading to 0.7.69 help ? 
> 
> Here is a summary of the network trace. I can provide the full trace if
> required.
> No.     Time                Source                Destination          
> Protocol Length Info
>  1  2011-12-05 23:06:51 92.90.19.29           94.143.115.73         TCP 
>     76     37352 > https [SYN] Seq=0 Win=64240 Len=0 
>  2  2011-12-05 23:06:51 94.143.115.73         92.90.19.29           TCP 
>     76     https > 37352 [SYN, ACK] Seq=0 Ack=1 Win=5792 
>  3  2011-12-05 23:06:52 92.90.19.29           94.143.115.73         TCP 
>     68     37352 > https [ACK] Seq=1 Ack=1 Win=64240 
>  4  2011-12-05 23:06:52 92.90.19.29           94.143.115.73        
> TLSv1    148    Client Hello
>  5  2011-12-05 23:06:52 94.143.115.73         92.90.19.29           TCP 
>     68     https > 37352 [ACK] Seq=1 Ack=81 Win=6144 
>  6  2011-12-05 23:06:52 94.143.115.73         92.90.19.29          
> TLSv1    1516   Server Hello
>  7  2011-12-05 23:06:52 94.143.115.73         92.90.19.29           TCP 
>     1516   [TCP segment of a reassembled PDU]

Two full-sized packets has been sent.  None of them has been 
ack'ed.  TCP stack will wait for an ack here, this is expected 
behaviour.

>  8  2011-12-05 23:06:56 94.143.115.73         92.90.19.29          
> TLSv1    1516   [TCP Retransmission] Server Hello
>  9  2011-12-05 23:07:02 94.143.115.73         92.90.19.29          
> TLSv1    1516   [TCP Retransmission] Server Hello
>  10 2011-12-05 23:07:14 94.143.115.73         92.90.19.29          
> TLSv1    1516   [TCP Retransmission] Server Hello
>  11 2011-12-05 23:07:39 94.143.115.73         92.90.19.29          
> TLSv1    1516   [TCP Retransmission] Server Hello

Four retransmission.  Still no ack from the client.

>  12 2011-12-05 23:07:52 92.90.19.29           94.143.115.73         TCP 
>     68     37352 > https [FIN, ACK] Seq=81 Ack=1 =64240 

FIN from the client.  Still no ack of the data sent.

This looks like client's problem, most likely it just can't 
receive full-sized packets due to network misconfiguration (likely 
low MTU on the network path and ICMP filtered).

Maxim Dounin