
Http-https transitions and relative URLs - johns
http://nedbatchelder.com/blog/200710/httphttps_transitions_and_relative_urls.html
======
calcnerd256
Man, I need to go read the spec for things like this. I had no idea relative
URIs relative to the protocol were legal.

------
keltex
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.

~~~
benatkin
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.

~~~
jhancock
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.

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

~~~
jhancock
hmmm...my mistake. ;) thanks

------
pasbesoin
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?

~~~
singlow
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.

~~~
pasbesoin
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.

~~~
cninja
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...](http://my.opera.com/yngve/blog/2008/05/23/lowering-the-ev-bar) I bring
this up to show that it is a tricky issue and even experts in the field
disagree about it.

~~~
pasbesoin
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.

~~~
singlow
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.

~~~
pasbesoin
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.

