If your internet traffic had an eavesdropper and you access a website using HTTPS from my understanding they would know the domain name (hostname) that you visit (as well as some other things), but if after logging into that first site (which is on HTTPS) another HTTPS page on another domain name (hostname) was loaded via an iframe would the eavesdropper be able to see this new domain name (hostname) or would this information be encrypted by the first HTTPS connection that was made?

3 Answers 3


I think you're asking:

If the page at https://host1/ contains an <iframe> which loads https://host2/, does that mean the HTTPS connection to host1 somehow wraps the connection to host2?

No. While it may seem natural to think that if one page visually envelops another, there may be something similar happening with the underlying connections, this is not the case.

Your browser creates distinct HTTPS connections to host1 and host2, and both in (more-or-less) the same manner. So if the hostnames would leak to an eavesdropper on the network if you opened them in separate tabs or windows, the same would apply if one loads the other in a frame. In fact, an observer of the two TLS connections wouldn't easily be able to tell whether the traffic represents two documents in an <iframe> relationship, or the user had simply first opened https://host1/ and then got redirected to https://host2/.

The notion of nested browsing contexts through HTML frames exists on the application layer and is mostly independent from how your browser secures data transport.

  • "Your browser creates distinct HTTPS connections to host1 and host2" - most times but not always. Please see what I've wrote in my answer about HTTP/2 connection coalescing. Nov 8, 2021 at 5:51

In most cases some man in the middle which is able to passively inspect the traffic can find out the hostname of all sites accessed. This is because this information is contained in the TLS handshake with this site, specifically the server_name extension (SNI - Server Name Indication) of the ClientHello.

It does not matter for this if the other site is accessed directly or using an iframe, i.e. iframe traffic will not be encrypted inside the existing TLS connection to the parent site. It also does not matter if the user is logged into the parent site or not.

There are some exceptions to this. Naturally the name can not be detected if the SNI is encrypted, i.e. ESNI. But in this case at least the IP address of the target site will be known to the attacker, which might help to determine what domain this might have been.

In addition to this there is some lesser known feature of HTTP/2 called connection coalescing. In this case access to different domains can be done over a single HTTP/2 connection, as long as both domains resolve to the same IP address and are covered by a single certificate. Only the first domain shows up in the SNI of the TLS handshake though, the other one is hidden from the passive attacker. The attacker can not even detect that different domains are accessed, all it sees is encrypted traffic to a specific IP address.

  • Yes, even with ESNI attacker will know IP address, but is usually even worse - attacker which can snoop your TLS traffic will often be able to snoop your DNS requests to, so they would likely be correlate that information (DoH/DoT which become popular lately would reduce that part of the risk, though, but IP address alone is huge telling today when world is moving away from shared hosting). Nov 8, 2021 at 16:08
  • 2
    @MatijaNalis: "... when world is moving away from shared hosting" - does it? And while not shared hosting an IP address might be less telling than in the past, since use of CDN is quite common. And a CDN has a lot of domains on the same IP. Nov 8, 2021 at 20:35
  • It's just my experience that there is the trend that the companies who were previously using shared hosting (or even self hosting) are moving to VPSs / cloud lately. Does your experience differ? You might have a point with CDN as I'm not sure about all of the offerings. But looking at security.stackexchange.com for example, its IP addresses on Fastly CDN seems to be SE-only, not shared with other entities? I gather from your answer that SE is outlier here, and that SNI-only TLS (as needed for "shared https on CDN") is widely used practice on CDNs? Can you give some examples of that? Nov 9, 2021 at 0:20
  • @MatijaNalis: Given that the amount on domains is growing and the amount of IPv4 addresses not and that there is probably no relevant IPv6 only domain there is no way to deal with this apart from sharing IPv4 addresses between domains. "... SE is outlier here ..." - it's not an outlier. stackoverflow.com, security.stackexchange.com, superuser.com ... all share the same IPs. Nov 9, 2021 at 5:24
  • Well, most of the new domains are scam/botnet only (mostly one-shot) and majority of the rest is use-2nd-level-domain-for-each-brand-because-SEO, so it is not particularly indicative either, IMHO. What I meant to indicate is that SE as the corporate entity has IPs that are not shared with other entities by Fastly CDN. The fact that SE chose to use one certificate with multiple SubjectAltNames is not relevant for most uses - after all, the fact that SE decided to use different domains/subdomains is an implementation detail: they might have as well used stackexchage.com/security instead Nov 9, 2021 at 6:24

A host name is never private in any TLS context, period.

@mentallurg answer is correct, but it is less obvious than simply that the subframe is defined by the parent frame because it is ubiquitous that a third party script include is all the parent frame adds unknowingly that such a script will then fetch other resources and create child frames.

This is how by including google tag manager (GTM) yourself, it will go fetch other scripts like google analytics (gapi) and when it loads in the parent frame it also goes and fetches more scripts to eventually include a script that will create an iframe and use the iframe context to store secret (actually it's not secret, maybe hidden is a better word) tokens.

Therefore, if you believe an iframe materialised without your knowledge or consent, you need to trace back the inclusion of the iframe because as @mentallurg stated you did actually decide to include it and actually included it at some point.

I wanted to know what someone observing the unencrypted traffic would see

The entire page, all frames, are on the endpoint.

TLS will protect data on the wire, but is designed to allow endpoints the ability to view the clear text contents of the TLS communications. i.e. the page and all frames are the endpoint and can easily access all data the endpoint has access to given protections on the endpoint itself.

You can restrict iframe permissions using sandbox attribute, if you created the iframe this is best because adding it afterwards is inefective. You can also send X-Frame-Options and Content-Security-Policy headers to control behaviours for iframes created by third parties.

But since you keep going back to the hostname concern in comments I want to repeat one simple fact; A host name is never private

  • This feels like it's answering another question: there is nothing in the question about "an iframe materialising without knowledge or consent", and the attacker is described as "an eavesdropper on your internet traffic", not software with access to the clear text inside the browser.
    – IMSoP
    Nov 9, 2021 at 14:06
  • You're making a distinction without a difference, an eavesdropper is not described by the OP so our intpretation using the meaning of the word applies, and my answer is one very valid interpretation given the act itself is an example of eavesdropping. If you did a threat modelling exercise and missed my scenario, it would be an incomplete model. And the fact the OP describes they want to hide things from an iframe implies they didnt create it, trust it, or know they have complete control, ergo they indicate it materiald without consent, not placed with consent obviously
    – Stof
    Nov 9, 2021 at 21:44

You must log in to answer this question.

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