Transitioning to HTTPS -- 28 Oct 2015

<mkwst> scribe: mkwst

bhill2: This is an idea at the "collection of interesting ideas" phase.
... no one's implemented, just freeform discussion.
... came up this summer during berlin F2F.
... "How do we encourage more HTTPS"?

<mt_____> "just turn off http://"

bhill2: what are obstacles.
... how do we get there without a flag day, without damaging the link structure of the web, etc.

<npdoty> When mkwest says "collection of interesting ideas", he usually has a complete draft of the spec :)

bhill2: Traditional wisdom: "Why aren't you on HTTPS" -> getting a cert is a pain.
... Let's Encrypt solves that! All done!
... Let's assume that Let's Encrypt gives you certs, and it just comes with Apache.
... If I have a modern website, I still can't just flip the switch.
... Because of Mixed Content.
... [explains dependency problem: http can load https, but not vice versa]
... I don't want to just flip over to HTTPS, because users will get a bad experience.
... Even if I just publish it, HTTPS Everywhere will find it, Google will promote it in search, etc.
... Users are going to have a bad time until I do a lot of work.
... Why is mixed content a problem?
... Do I need to go into this?.

<npdoty> Completely hypothetical example of large static site like w3.org

[No.]

bhill2: How do we fix mixed content?
... Upgrade-Insecure-Requests is one answer.
... Just upgrades all requests from http to https, assertion from the site that the resources are semantically equivalent.
... If I just add this header, many problems are fixed.

<inserted> explanation of upgrade-insecure-requests

bhill2: Deadlock in upgrading if one dependency isn't upgraded.
... Deadlocks cascade. Dependencies between websites create upgrade problems.
... How do we break the deadlock?
... Introduce an intermediary state.

<npdoty> Opportunistic, I think, right?

bhill2: Like opportunistic encryption, but with similar properties to "real" encryption.
... Keep "principle of tranquility" by not treating it as secure in the UI (like OE)
... But this optimistic mode would not be treated as mixed content for subresource loads.
... Zero cost, zero risk. Happy users. Anyone depending on me is unblocked.

<npdoty> I'm not sure what "optimistic" means, or if it's synonymous to opportunistic... Or if opportunistic is well defined either

bhill2: Would it be sufficient to allow everything but HTML pages?
... Iframes cause problems, because dependencies that go from HTML to HTML across origin boundries.
... Idea to solve this is the transitional mode via a new ALPN protocol.
... [explains ALPN]
... [https://tools.ietf.org/html/rfc7301]
... Client indicates protocols it's willing to support, server chooses one.
... No additional roundtrip.
... Origin A that depends on Origin B can load resources from origin B iff Origin B supports the transitional mode:
... Initiate a connection to B on 443, tell the server that you support either "real" HTTPS or transitional HTTPS.
... Server can decide what to deliver back to the client.

?: What's different from server B's point of view?

bhill2: Transitional provides a few things.
... 1. It provides a contract which says
... The content provided over transitional is semantically identical to the response it would give over HTTP.
... http://forbes.com != https://forbes.com
... This gives assurances that the two are the same.

martin: HSTS is a signal of equivalence.

[side conversations]

JeffH: HSTS isn't equivalence. It breaks HTTP and replaces it.

martin: It also states that on the transitional indicator. This is analogous to the HSTS signal.

JeffH: But two different policies.

rbarnes: I don't understand the distinction you're making.
... HSTS says that the authoritative version is HTTPS.

JeffH: And HSTS says that there is no HTTP version.

rbarnes: But either way, you're going to HTTPS, right?

dan: That works if you're the provider, but not if you're the consumer of those resources.

rbarnes: Non-determinism is a solvable problem. I have a proposal for priming that's floating around.

zcorpan: What should the client do differently when this is present?

bhill2: Two modes: when you fetch a resource as a top-level resource, and when the content is loaded as a subresource.
... When A loads B over transitional, A doesn't have mixed content warnings.
... When B is a top-level navigation, you upgrade the transport, but don't treat it as secure.

<npdoty> You don't enforce Mixed Content blocking and you don't show a nice lock icon?

dbaron: When it's a subresource of an HTTPS resource, right?

bhill2: When transitional is loaded as top-level, UA doesn't show a lock lock, won't claim to be HTTPS, won't block mixed content.
... Don't provide a bad experience for my users, and folks who depend on me can do so securely.

rbarnes: What about iframed iframes?

bhill2: Right. Insecurely framed documents would still break. This doesn't fix them.

martin: How do you get to transitional for origin B?

<npdoty> Are we incentivized to just all go to transitional?

bhill2: Land on it with HTTP, and either the browser tries 443 optimistically, or we do alt-src header.

mnot: Probably need to do the latter.

bhill2: Sure. Maybe we do that in the future, maybe HTTPS Everywhere makes that a pref. Who knows.

[something about upgrade-insecure-requests that I missed.]

bhill2: If you have upgrade-insecure-requests set, it attempts the load over 443.
... Right now, folks don't want to turn that on because it exposes users to broken experiences.
... Can do it optimistically without providing broken experiences.

yoav: Transitional gives you the option of upgrading?

bhill2: Right. There's practically zero risk of breaking clients with transitional.
... User would never see a mixed content warning by visiting your page.

yoav: What are the advantages of using this? You don't get service workers, no secure contexts, etc?
... But you do get HTTP/2, right?

bhill2: Transport layer is distinct. You get all that, but you don't get the promises of HTTPS. No mixed content, no secure context, etc.
... Eventually I can flip a second switch, say "I'm tranquil. Sure, you said HTTP, but I'm really HTTPS, so enforce all that on me."

martin: Couldn't you just HSTS at that point?

bhill2: Sure, but there are billions of links in databases.

tim: Paper documents!

JeffH: The intention ... this could be a rathole ... The HSTS policy statement doesn't imply that anything is available over HTTP.
... Even though there's URL rewriting, what drove us to flip the scheme was usability on the user's part.
... Not to make a statement that HTTP is semantically equivalent to HTTPS.

rbarnes: Maybe morally you're not, but effectively you are.

bhill2: HTTPS categorically blocks because of mixed content in status quo.
... Network stack folks don't want to change that.
... Contract is also to developers: fail fast, fail hard.
... Enables a gradual transition rather than flag days and emergency sirens.

JeffH: This policy is about semantic equivalents. HSTS doesn't make that promise.

tim: The promise is relevant for semantic web.
... Devices do canonicalization on URLs anyway.
... Will there be an API to look at my XHR in some way to tell me about the commitments made by the other side?

bhill2: URL wouldn't change. Just behind the scenes guts.
... URL doesn't change, so you can implicitly assume the semantic equivalence.

<rbarnes> JeffH: i would be totally in favor of updating HSTS to make the statement of semantic equivalence

<rbarnes> since everybody already thinks it does :)

tim: Imagine I fetch one thing from a server, that gives me knowledge of that URI. What do I do for other URIs?

bhill2: This doesn't address that.
... This lets you access a service over TLS that makes a guarantee that a resource is semantically equivalent to the one over a non-TLS channel.
... "Is there a way for an application to know that HTTPS == HTTP for an origin?"
... No, not today, and no that's not part of this proposal.
... This lets you try a connection, and ensure that you get such a resource back.

rbarnes: We should update HSTS so that it's a guarantee of equivalence.

JeffH: It would require changes to browsers.

tim: First write in the spec that HSTS makes that commitment.
... Then, having that commitment, get the information to the application.

JeffH: Altering the semantics of HSTS might be a way to address this if browsers are on board.

rbarnes: Given that the browser behavior 80% implements the equiv. right now, it seems simpler to just change it.

bhill2: That addresses Tim's use case, but not the more important use case of getting folks to TLS without a flag day.

JeffH: Maybe we could implement all this under the HSTS policy.

bhill2: I think you need a way to break the deadlocks.

rbarnes: Do you have examples of the deadlock problem.

tim: w3.org.
... He's in the building.
... You tell us to go to Ted, and tell him to turn on HTTPS.
... circular dependencies.

bhill2: We have evidence of this. Easy. Ad networks.

rbarnes: This is a telemetry problem.
... The word we used was "transitional". What gets folks to transition?

tim: This works! we get to the blue state!
... If everyone is blue, we're secure.

rbarnes: No, blue isn't secure!

bhill2: Blue lets you discover what content would have been loaded without mixed content blocking.

rbarnes: Maybe this is a report-only mode of upgrade insecure requests.
... Maybe that's simpler to conceptualize than a third mode.

bhill2: The blue state is easy! Don't care, we just turn it on for you.

fluffy: What if firewall blocks 443?

bhill2: Won't be worse than status quo. If you don't send the alt-srv header, no risk of breakage.
... The goal is turn it on, no breakage.
... This is meant to break the deadlocks.
... Once everyone is transitional because it's free, or, if not everyone, more than status quo, deadlocks are broken.
... Which is a virtuous cycle.

timeless: What's the timeline? At what point could we just switch?

<scribe> scribe: yoav

bhill2: It would be simple to build this into nginx/Apache

<npdoty> scribenick: yoav

bhill2: Set your config to connect ALPN token to the right port

timeless: You want it in all servers in the world
... So some sites will turn blue after a few months, and some sites will never be blue

<dveditz> server stacks: apache, tomcat, iis, custom CDN stacks, etc

timeless: so after a while, we have to decide everything is green and everything will break

bhill2: You're probably right, some sites will never upgrade and that's it, but at some point, if we'd stop support
... there would be a flag day, but this will enable us to move more people sooner
... by enabling more sites to move to that transitional state

<rbarnes> BLUE IS NOT SECURE

tbl: supposed that we came back in 4 years and everything is blue, transitional but completely secure

timeless: I would be happy, but we'd switch it

mt_____: blue is vulnerable to downgrade attacks, so you don't want that long term
... so it's not perfect, but better than nothing

mt: So we won't want to support blue indefinitely
... maybe we can re-examine the HSTS thing

bhill2: Once I''ve set the tranquil flag you should treat the site as HTTPS, but I still have HTTP links

mt: What we want is to get everyone to secure state

bhill2: we want to get everyone there without breaking their sites, nor the guaranties

rbarnes: this proposal is conflating two mechanisms
... one is getting better telemetry

bhill2: fixing mixed content breakage is very exepnsive, so the most important thing is unblocking dependers

rbarnes: it would be useful to break out all the parts because they may have different solutions

bhill2: I like it since it solves all the use cases

<npdoty> On that last point, it seems uncertain whether we can safely unblock people who depend on us by providing parallel http/https without endangering anything

rbarnes: but you're bundling the different use cases into a single solution

tbl: what telemetry would one need? When measuring the dependencies don't we know what they are but the graph is too complicated?
... the ability to go to blue stage is important

rbarnes: if we do the first two things, we'd still have to get to blue stage
... but sites that I've worked with were able to get the first two
... so once we've handled that we can know what we need to do about the more complicated things

bhill2: thinking about cost and incentive
... sites want the lock icons
... so they can use that to discover the dependencies and apply pressure

rbarnes: the blue state removes pressure from the 3rd party to moving to HTTPS

tbl: if you're serving scripts you will get pressure

barryleiba: but you're getting nothing out of at

npdoty: if you're an ad network, you're losing money

mt: I'd like to push back on the "just work" concept
... if you look into the details, there are a lot of operational problems that this doesn't avoid
... we ran into problems, because you're running on TLS in a modified mode, so resources are requested over blue mode and green mode, and it's gets complicated to deploy this
... you're selling a silver bullet, and we've been there

bhill2: I'd love comments about these issues

<barryleiba> turns out to be a tin bullet...

mt: we've been discussing that almost two years
... I'm suggesting that this shares some problems with opportunistic encryption

mnot: I'd love to hear the editor of the mixed content spec

mkwst: If we can get the same guaranties, it's not mixed content
... my concerns
... a) what thos guaranties are?
... the proposal addresses that, so if guaranties are provided, resource doesn't load
... you lose confidentiality
... you keep the rest
... I'd love to keep confidentiality
... so that if we're coming from a secured context we request 443
... HTST probing forces you into HSTS which is problematic
... what I've heard is that they can't do HSTS now, they dont HTTPS
... HSTS is hard, so decoupling from HSTS is better
... my impression is that it resolves a small number of sites
... it's not clear that it's worth doing the work
... and it doesn't solve the bigger problem of getting people migrate
... what happens is that someone at the end of the chain doesn't migrate
... which prevents everyone from migrating
... one option is the block mixed content, instead of loading and breaking UI

<rbarnes> list of Let's Encrypt certificates

mkwst: ads not being HTTPS is going away
... every publisher is moving to HTTPS
... so the guaranties of HTTPS are enough to get people to migrate
... I'm sympathetic to the problems this is solving
... not clear this is relevant in a few years
... concerned about the amount of work that this would be involved
... or if it's better to get more certs into hands of people
... and resolving telemetry issue rbarnes talked about
... but people care and are working on it
... some sites will never upgrade, but not clear what we do with them
... this proposal will get us to these sites, but I suspect that there are a lot of them
... they probably not a dependencies so fairly isolated

bhill2: the rock they're under might be a government with data

mkwst: upgrading to HTTPS won't solve it
... I think it's worth exploring, I want to understand implications on ecosystem
... if it helps everyone upgrade, that's great
... or maybe we talk to large hosters and they just upgrafde

bhill2: they can't necessarily upgrade because of crazy content that's linking anywhere

tbl: there was a plan to switch before TPAC, but too much stuff broke

mkwst: we asked questions and no answer

yves: problems with Firefox not implementing upgrade

mkwst: Safari didn't implement either, you need to cope

bhill2: thanks for showing up

[ Adjourned ]

<bhill2> adjourned!

<npdoty> Thanks, Brad!

- DRAFT -

Transitioning to HTTPS

28 Oct 2015

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output