Return to Answer

I see there are no Client Hello messages with the mail.yahoo.com name in the SNI extension field.

Every ClientHello in both pcaps you've provided has a server_name extension with the name of the target server. There is no connection with a ClientHello for mail.yahoo.com in the second pcap though which matches your description.

There are several other TLS connections though which are captured somewhere in the middle, i.e. without the TLS handshake and thus the ClientHello captured. For example the second TCP stream in the packet capture matches the IP address of mail.yahoo.com from your first packet capture. This indicates that it is using an already established TCP connection (with TLS on top).

Note that your first packet capture indicates that a connection to mail.yahoo.com is actually successful, i.e. it is not blocked as you claim (TCP connection number 6). The connection you see in the second packet capture might actually be the previously unblocked connection to mail.yahoo.com which you cannot block now since no new TCP+TLS connection was established and thus no new ClientHello was send. But it might also be a connection which had a different server_name in the ClientHello.

Is the browser somehow using the same TLS session since the *.yahoo.com certificate is valid for both www.yahoo.com and mail.yahoo.com?

If the inner protocol is HTTP/2 the client is allowed to use an existing TCP connection to the same IP address provided that the certificate matches the authority part of the URL (i.e. the domain) too. See RFC 7540 section 9.1.1. This would explain that no new connection (with a new ClientHello) would be created and thus that your filter failed to detect and block the access. Thanks for HelpingHand to pointing to this standard.

I see there are no Client Hello messages with the mail.yahoo.com name in the SNI extension field.

Every ClientHello in both pcaps you've provided has a server_name extension with the name of the target server. There is no connection with a ClientHello for mail.yahoo.com in the second pcap though which matches your description.

There are several other TLS connections though which are captured somewhere in the middle, i.e. without the TLS handshake and thus the ClientHello captured. For example the second TCP stream in the packet capture matches the IP address of mail.yahoo.com from your first packet capture. This indicates that it is using an already established TCP connection (with TLS on top).

Note that your first packet capture indicates that a connection to mail.yahoo.com is actually successful, i.e. it is not blocked as you claim (TCP connection number 6). The connection you see in the second packet capture might actually be the previously unblocked connection to mail.yahoo.com which you cannot block now since no new TCP+TLS connection was established and thus no new ClientHello was send. But it might also be a connection which had a different server_name in the ClientHello.

Is the browser somehow using the same TLS session since the *.yahoo.com certificate is valid for both www.yahoo.com and mail.yahoo.com?

If the inner protocol is HTTP/2 the client is allowed to use an existing TCP connection to the same IP address provided that the certificate matches the authority part of the URL (i.e. the domain) too. See RFC 7540 section 9.1.1. This would explain that no new connection (with a new ClientHello) would be created and thus that your filter failed to detect and block the access. Thanks for HelpingHand to pointing to this standard.

I see there are no Client Hello messages with the mail.yahoo.com name in the SNI extension field.

Every ClientHello in both pcaps you've provided has a server_name extension with the name of the target server. There is no connection with a ClientHello for mail.yahoo.com in the second pcap though which matches your description.

There are several other TLS connections though which are captured somewhere in the middle, i.e. without the TLS handshake and thus the ClientHello captured. For example the second TCP stream in the packet capture matches the IP address of mail.yahoo.com from your first packet capture. This indicates that it is using an already established TCP connection (with TLS on top).

Note that your first packet capture indicates that a connection to mail.yahoo.com is actually successful, i.e. it is not blocked as you claim (TCP connection number 6). The connection you see in the second packet capture might actually be the previously unblocked connection to mail.yahoo.com which you cannot block now since no new TCP+TLS connection was established and thus no new ClientHello was send.

Is the browser somehow using the same TLS session since the *.yahoo.com certificate is valid for both www.yahoo.com and mail.yahoo.com?

If the inner protocol is HTTP/2 the client is allowed to use an existing TCP connection to the same IP address provided that the certificate matches the authority part of the URL (i.e. the domain) too. See RFC 7540 section 9.1.1. This would explain that no new connection (with a new ClientHello) would be created and thus that your filter failed to detect and block the access. Thanks for HelpingHand to pointing to this standard.

I see there are no Client Hello messages with the mail.yahoo.com name in the SNI extension field.

Every ClientHello in both pcaps you've provided has a server_name extension with the name of the target server. There is no connection with a ClientHello for mail.yahoo.com in the second pcap though which matches your description.

There are several other TLS connections though which are captured somewhere in the middle, i.e. without the TLS handshake and thus the ClientHello captured. For example the second TCP stream in the packet capture matches the IP address of mail.yahoo.com from your first packet capture. This indicates that it is using an already established TCP connection (with TLS on top).

Note that your first packet capture indicates that a connection to mail.yahoo.com is actually successful, i.e. it is not blocked as you claim (TCP connection number 6). The connection you see in the second packet capture might actually be the previously unblocked connection to mail.yahoo.com which you cannot block now since no new TCP+TLS connection was established and thus no new ClientHello was send. But it might also be a connection which had a different server_name in the ClientHello.

Is the browser somehow using the same TLS session since the *.yahoo.com certificate is valid for both www.yahoo.com and mail.yahoo.com?

If the inner protocol is HTTP/2 the client is allowed to use an existing TCP connection to the same IP address provided that the certificate matches the authority part of the URL (i.e. the domain) too. See RFC 7540 section 9.1.1. This would explain that no new connection (with a new ClientHello) would be created and thus that your filter failed to detect and block the access. Thanks for HelpingHand to pointing to this standard.

I see there are no Client Hello messages with the mail.yahoo.com name in the SNI extension field.

Every ClientHello in both pcaps you've provided has a server_name extension with the name of the target server. There is no connection with a ClientHello for mail.yahoo.com in the second pcap though which matches your description.

There are several other TLS connections though which are captured somewhere in the middle, i.e. without the TLS handshake and thus the ClientHello captured. For example the second TCP stream in the packet capture matches the IP address of mail.yahoo.com from your first packet capture. This indicates that it is using an already established TCP connection (with TLS on top).

Note that your first packet capture indicates that a connection to mail.yahoo.com is actually successful, i.e. it is not blocked as you claim (TCP connection number 6). The connection you see in the second packet capture might actually be the previously unblocked connection to mail.yahoo.com which you cannot block now since no new TCP+TLS connection was established and thus no new ClientHello was send.

I see there are no Client Hello messages with the mail.yahoo.com name in the SNI extension field.

Every ClientHello in both pcaps you've provided has a server_name extension with the name of the target server. There is no connection with a ClientHello for mail.yahoo.com in the second pcap though which matches your description.

There are several other TLS connections though which are captured somewhere in the middle, i.e. without the TLS handshake and thus the ClientHello captured. For example the second TCP stream in the packet capture matches the IP address of mail.yahoo.com from your first packet capture. This indicates that it is using an already established TCP connection (with TLS on top).

Note that your first packet capture indicates that a connection to mail.yahoo.com is actually successful, i.e. it is not blocked as you claim (TCP connection number 6). The connection you see in the second packet capture might actually be the previously unblocked connection to mail.yahoo.com which you cannot block now since no new TCP+TLS connection was established and thus no new ClientHello was send.

Is the browser somehow using the same TLS session since the *.yahoo.com certificate is valid for both www.yahoo.com and mail.yahoo.com?

If the inner protocol is HTTP/2 the client is allowed to use an existing TCP connection to the same IP address provided that the certificate matches the authority part of the URL (i.e. the domain) too. See RFC 7540 section 9.1.1. This would explain that no new connection (with a new ClientHello) would be created and thus that your filter failed to detect and block the access. Thanks for HelpingHand to pointing to this standard.