1

I noticed this while testing SNI-based HTTPS filtering for fun. My test was to block mail.yahoo.com, but allow other yahoo.com services. Here are my tests using Chrome:

  1. Access mail.yahoo.com by entering the full URL https://mail.yahoo.com: BLOCKED

  2. Access mail.yahoo.com by logging into my Yahoo account via https://yahoo.com, and clicking the "Mail" link: NOT BLOCKED

I ran a packet capture while re-creating test #2 and I see there are no Client Hello messages with the mail.yahoo.com name in the SNI extension field. This is why I assume the web filter, which relies on inspecting the SNI extension field, is not blocking the website.

I am trying to understand why I wouldn't see a Client Hello message w/ mail.yahoo.com in the SNI field when running test #2. 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? I am interested to know more about how this works.

Improve this question
6
  • It is not clear what you mean with "is blocked when accessed directly" nor is it clearly what you've actually seen exactly in the packet capture. I have the feeling that there are some misinterpretations of what you actually saw or that you've looked at the wrong data. But since it is not fully clear what you did I cannot reproduce it and you do not provide any packet captures either - just your interpretation. It would be better if you provide all the details needed to reproduce your experiments in your question instead of only asking question which might be based on a wrong interpretation.
    – Steffen Ullrich
    Commented Jan 2, 2020 at 19:26
  • Hi Steffen, I've edited my post to try and make it more clear.
    – pr112w
    Commented Jan 2, 2020 at 20:46
  • "I ran a packet capture while re-creating test #2 and I see there are no Client Hello messages with the mail.yahoo.com name in the SNI extension field." - even if it would reuse the same TLS session (which it likely does not) the SNI would still be in the ClientHello. Please provide the packet capture to see what really is going on.
    – Steffen Ullrich
    Commented Jan 2, 2020 at 21:10
  • 1
    Connection reuse - tools.ietf.org/html/rfc7540#section-9.1.1 ?
    – HelpingHand
    Commented Jan 2, 2020 at 21:10
  • HTTP/2 Connection Reuse sounds like a possibility, I will need to start reading. Thank you for the link. @Steffen Ullrich: I've updated the post w/ links to some basic captures.
    – pr112w
    Commented Jan 2, 2020 at 21:21

1 Answer 1

Reset to default
0

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.

Improve this answer
1
  • @pr112w: see updated answer.
    – Steffen Ullrich
    Commented Jan 2, 2020 at 22:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .