[
https://issues.apache.org/jira/browse/TS-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Ivanov updated TS-2941:
------------------------------
Description:
We are seeing lots of RSTs on our edge boxes from HTTPS-enabled clients:
{code}
20:31:43.743987 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
441162518, win 7944, options [nop,nop,TS val 1060728286 ecr 579956131], length 0
20:31:43.743994 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
1449, win 8192, options [nop,nop,TS val 1060728286 ecr 579956132], length 0
20:31:43.895889 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
1467, win 8190, options [nop,nop,TS val 1060728437 ecr 579956371], length 0
20:31:54.189610 IP www.linkedin.com.https > client-ip.56898: Flags [F.], seq
1467, ack 0, win 167, options [nop,nop,TS val 579966817 ecr 1060728437], length 0
20:31:54.305500 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
1468, win 8192, options [nop,nop,TS val 1060738819 ecr 579966817], length 0
20:31:54.775695 IP client-ip.56898 > www.linkedin.com.https: Flags [P.], seq
0:69, ack 1468, win 8192, options [nop,nop,TS val 1060739277 ecr 579966817],
length 69
20:31:54.775732 IP www.linkedin.com.https > client-ip.56898: Flags [R], seq
441163985, win 0, length 0
20:31:54.775739 IP client-ip.56898 > www.linkedin.com.https: Flags [F.], seq
69, ack 1468, win 8192, options [nop,nop,TS val 1060739277 ecr 579966817],
length 0
20:31:54.775743 IP www.linkedin.com.https > client-ip.56898: Flags [R], seq
441163985, win 0, length 0
{code}
You can see that after proxy.config.http.keep_alive_no_activity_timeout_in ATS
is close(2)ing TLS connection without sending TLS close_notify alert which
results in client sending it, but because socket is already closed OS replies
with RST.
>From standard [RFC5246]:
{code}
Unless some other fatal alert has been transmitted, each party is
required to send a close_notify alert before closing the write side
of the connection. The other party MUST respond with a close_notify
alert of its own and close down the connection immediately,
discarding any pending writes. It is not required for the initiator
of the close to wait for the responding close_notify alert before
closing the read side of the connection.
{code}
[RFC5246] http://tools.ietf.org/html/rfc5246#section-7.2.1
PS. Is anyone seeing that behaviour on prod. boxes?
PPS. [~briang] can you take a look at it?
was:
We are seeing lots of RSTs on our edge boxes from HTTPS-enabled clients:
{code}
20:31:43.743987 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
441162518, win 7944, options [nop,nop,TS val 1060728286 ecr 579956131], length 0
20:31:43.743994 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
1449, win 8192, options [nop,nop,TS val 1060728286 ecr 579956132], length 0
20:31:43.895889 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
1467, win 8190, options [nop,nop,TS val 1060728437 ecr 579956371], length 0
20:31:54.189610 IP www.linkedin.com.https > client-ip.56898: Flags [F.], seq
1467, ack 0, win 167, options [nop,nop,TS val 579966817 ecr 1060728437], length 0
20:31:54.305500 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
1468, win 8192, options [nop,nop,TS val 1060738819 ecr 579966817], length 0
20:31:54.775695 IP client-ip.56898 > www.linkedin.com.https: Flags [P.], seq
0:69, ack 1468, win 8192, options [nop,nop,TS val 1060739277 ecr 579966817],
length 69
20:31:54.775732 IP www.linkedin.com.https > client-ip.56898: Flags [R], seq
441163985, win 0, length 0
20:31:54.775739 IP client-ip.56898 > www.linkedin.com.https: Flags [F.], seq
69, ack 1468, win 8192, options [nop,nop,TS val 1060739277 ecr 579966817],
length 0
20:31:54.775743 IP www.linkedin.com.https > client-ip.56898: Flags [R], seq
441163985, win 0, length 0
{code}
You can see that after proxy.config.http.keep_alive_no_activity_timeout_in ATS
is close(2)ing TLS connection without sending TLS close_notify alert which
results in client sending it, but because socket is already closed OS replies
with RST.
>From standard {{RFC5246}}:
{code}
Unless some other fatal alert has been transmitted, each party is
required to send a close_notify alert before closing the write side
of the connection. The other party MUST respond with a close_notify
alert of its own and close down the connection immediately,
discarding any pending writes. It is not required for the initiator
of the close to wait for the responding close_notify alert before
closing the read side of the connection.
{code}
{{[RFC5246]}} http://tools.ietf.org/html/rfc5246#section-7.2.1
PS. Is anyone seeing that behaviour on prod. boxes?
PPS. [~briang] can you take a look at it?
> ATS not closing TLS connection properly
> ---------------------------------------
>
> Key: TS-2941
> URL: https://issues.apache.org/jira/browse/TS-2941
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
> Reporter: Alexey Ivanov
>
> We are seeing lots of RSTs on our edge boxes from HTTPS-enabled clients:
> {code}
> 20:31:43.743987 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 441162518, win 7944, options [nop,nop,TS val 1060728286 ecr 579956131],
> length 0
> 20:31:43.743994 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 1449, win 8192, options [nop,nop,TS val 1060728286 ecr 579956132], length 0
> 20:31:43.895889 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 1467, win 8190, options [nop,nop,TS val 1060728437 ecr 579956371], length 0
> 20:31:54.189610 IP www.linkedin.com.https > client-ip.56898: Flags [F.], seq
> 1467, ack 0, win 167, options [nop,nop,TS val 579966817 ecr 1060728437],
> length 0
> 20:31:54.305500 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 1468, win 8192, options [nop,nop,TS val 1060738819 ecr 579966817], length 0
> 20:31:54.775695 IP client-ip.56898 > www.linkedin.com.https: Flags [P.], seq
> 0:69, ack 1468, win 8192, options [nop,nop,TS val 1060739277 ecr 579966817],
> length 69
> 20:31:54.775732 IP www.linkedin.com.https > client-ip.56898: Flags [R], seq
> 441163985, win 0, length 0
> 20:31:54.775739 IP client-ip.56898 > www.linkedin.com.https: Flags [F.], seq
> 69, ack 1468, win 8192, options [nop,nop,TS val 1060739277 ecr 579966817],
> length 0
> 20:31:54.775743 IP www.linkedin.com.https > client-ip.56898: Flags [R], seq
> 441163985, win 0, length 0
> {code}
> You can see that after proxy.config.http.keep_alive_no_activity_timeout_in
> ATS is close(2)ing TLS connection without sending TLS close_notify alert
> which results in client sending it, but because socket is already closed OS
> replies with RST.
> From standard [RFC5246]:
> {code}
> Unless some other fatal alert has been transmitted, each party is
> required to send a close_notify alert before closing the write side
> of the connection. The other party MUST respond with a close_notify
> alert of its own and close down the connection immediately,
> discarding any pending writes. It is not required for the initiator
> of the close to wait for the responding close_notify alert before
> closing the read side of the connection.
> {code}
> [RFC5246] http://tools.ietf.org/html/rfc5246#section-7.2.1
> PS. Is anyone seeing that behaviour on prod. boxes?
> PPS. [~briang] can you take a look at it?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
