Http-https transitions and relative URLs | Hacker News Reader

Http-https transitions and relative URLs

nedbatchelder.com

82 pointsjohns14 comments

Man, I need to go read the spec for things like this. I had no idea relative URIs relative to the protocol were legal.

The problem with this technique is that CDNs usually don't support HTTPS. It would require a dedicated IP address for the CDN and a separate certificate. The only thing I've been able to come up with is to replace http://cdn.example.com with https://www.example.com on SSL pages.

DHH has a solution to this problem that I like: http://gist.github.com/29752

It's rails code, but the concept could be ported to other languages/frameworks.

WOW!!! Why is this ever hitting the ruby process? These are static assets. The decision should be made at the http proxy (apache, nginx) not your ruby proc.

This controls which URLs are included in the dynamic content. It's not serving the actual assets.

hmmm...my mistake. ;) thanks

The two CDNs that I'm most familiar with (Akamai and Cotendo) do offer CDN/DSA services over SSL. I would imagine that the other big CDNs also offer SSL service. (Otherwise, how would they compete for e-commerce business?)

We pay Akamai a non-trivial amount of money for SSL service, and they in fact host separate certificates for us (in addition to our origin servers hosting "our" own [different] certificates).

So, this represents your (the user's) agreement to also trust the linked third party? How do browsers display this additional trust / certificate?

Edit: Just to clarify, even if the certificate is authenticated, it is STILL bringing the third party into the communication. Or am I misunderstanding the implications?

The issue you bring up is valid, but not related to the URL pattern. The URL pattern only saves the web server or coder from substituting the appropriate protocol prefix when serving pages with absolute urls.

Whether the url has explicit http or https prefixes should not affect how your browser negotiates the connection to external domains.

My point is that while I may trust domain X, this does not mean I trust domain Y. (Maybe they are not malicious, but I consider their security measures to be sub-par.)

If domain X starts referencing material from domain Y within its secure pages, I would like to be aware of this. My understanding is that once such material is incorporated into the browser-constructed page representation, it has full access to that representation. If the inclusion is a component that has the ability to control the browser (e.g. a script), then that component can observe or manipulate the page and its activity.

That is one reason not to trust an https page that includes content references/retrieved via http; the latter is easily subjected to a man in the middle attack.

The technique described in the article avoids this point, but it doesn't describe what if any notice browsers provide to the user that a second, authenticated domain/certificate is involved in the current communication.

Maybe I'm incorrect in my understanding (I'm no expert in this, by any means). But this is what forms the basis of my question.

Edit: I'll leave my question as a testament to my over-tired, over-caffeinated rashness. I take your point now, more fully, that specifying a link having the protocol prefixed, as opposed to this, will produce the same result end in the browser.

So, I guess my question reduces to a "browser 101" question of what does happen under those circumstances, with regard to browser presentation. Which I really should be able to determine on my own, with a bit of googling and/or experimentation.

My apology for putting my typing ahead of more collected thought.

I haven't spent much time addressing this particular area. Most of my work has been more behind the scenes and in communications paths where trust is already established.

You are correct. The theory is that if the trusted domain X is willing to embed links that point to domain Y, then the browser should be ok with it to. No additional notification passed to the browser.

When EV certificates came out (the super HTTPS verification that turns the address bar green), Opera developers and the standards body had differing opinions about this very issue. http://my.opera.com/yngve/blog/2008/05/23/lowering-the-ev-ba... I bring this up to show that it is a tricky issue and even experts in the field disagree about it.

I need to look further, but so far it appears to me that when one chooses in a browser to view the certificate chain of a secure page, where that secure page references secure content from/using third party domains/certificates, only the certificate chain of the top level page is displayed. The other certificate chains involved are essentially hidden unless one views the page source or runs a traffic sniffer. Is that correct?

If so, I'd prefer an option to see all the certificate chains involved in loading a page's content. Maybe most users won't care, but some will, and it would keep those details from remaining hidden or difficult/time consuming to access.

Somewhat related to this, I continue to be somewhat frustrated at the amount of dialog navigation that is required to view certificate chains in some browsers (e.g. Firefox 3 made the chain viewing dialog deeper nested within a hierarchy of dialog navigation).

My perspective is that, even when users don't fully understand an item, they are good at noticing changes -- we're wired to do so. If the chain is easily accessed, and users are taught to give it a glance, they are likely to notice if/when it changes, particularly for regularly visited sites. They may not know exactly what is going on, but it would likely be enough to inject caution and a google (twitter, whatever) for answers.

What does this have to do with the URL scheme though? With or without it, secure pages can embed links to other secure pages on other domains. Whether the protocol is explicit in the markup does not change the browsers ability to mix content from multiple secure domains.

I was asking a separate question, making a separate comment. Sorry if it seems too far off from the original article's topic, but cninja seems to have a lot of background in this area. I though that if he or another chose to respond again, it might clarify things for me, and maybe some other readers.

Perhaps I should have waited before responding; I'm (still) feeling kind of off, today. Apologies to anyone annoyed by my contributions here.

Reply on news.ycombinator.com