path: root/https.txt

Google, Mozilla, the EFF and others are and have been for some time pushing for websites to adopt HTTPS. Moving the bulk of the web from regular HTTP, which is an unencrypted connection that anyone can intercept, record and even manipulate, to HTTPS, which is encrypted and (reasonably) secure is overall a huge win for the web, which is to say us, the users of the web.

Changing the web to HTTPS is not, however, entirely without costs and challenges for web users and for website owners. The question is, do the benefits justify the costs? To answer that we have to first look at what HTTPS gets us and what it costs.

The major benefit of HTTPS is encryption. When your browser connects to a website over HTTPS the connection from your browser to the page you want to view is encrypted. Any data exchanged is not visible to anyone else snooping the network. And by anyone else I mean just that, anyone, could be Google, Verizon, the suspicious looking pale kid in the black hoodie sitting in the corner at the coffeeshop. 

Having an encrypted connection gets you one other thing -- authentication. 

Knowing that no one else on the network can read your traffic is good, but totally meaningless if you can't verify that the site you're visiting is actually the site you want to visit. To authenticate your connection to the site you're trying to visit your browser maintains a list of known, trusted certificate authorities. When your browser requests a secure page it gets the page's security certificate, which contains a chain that leads back to a certificate authority. If that authority matches an authority known to your browser then your browser will trust that the site you're connecting to is who it claims to be.

This is the single biggest problem with HTTPS. More on this in a minute.

Behind the scenes what handles all the encryption and authetication is a bit of technology know as TLS, which is short for Transport Layer Security. In fact the full name of HTTPS is really HTTP over TLS. TLS is the successor to the now vulnerable Secure Sockets Layer (SSL), though just to further complicate things you will often hear both referred to as "SSL". TLS is made up of two layers, the TLS Record Protocol and the TLS Handshake Protocol. Together these two tools allow your web browser to securely connect to a validated site and encrypt all your communications thereafter.

Only one bit of data leaks out in this scenario -- the name of the site you're visiting. When your browser loads arstechnica.com it must first ask a DNS server to translate arstechnica.com into a numeric IP address. The process of querying a DNS server is (currently) not encrypted. 

That means anyone snooping on your browsing session can get one bit of metadata -- they know you visited arstechnica.com. They don't know you're reading this specific article, but they do know you visited the site. Before you dismiss this metadata leak as unimportant, consider that the former head the NSA has publicly announced that the U.S. will "kill people based on metadata", even though, it seems, [many of those people may have been innocent](http://arstechnica.co.uk/security/2016/02/the-nsas-skynet-program-may-be-killing-thousands-of-innocent-people/). 

Now that you know what HTTPS offers -- encryption and authentication -- it should hopefully be obvious why your bank uses it, why Gmail, Facebook, Twitter and any other site you log in to uses it, or should (if you login into to site without it, stop visiting that site).

What's less immediately obvious is why *every* site needs to be HTTPS. In fact there has been considerable push-back against the effort to push the web to all HTTPS, all the time. Developer Dave Winer [calls HTTPS](http://scripting.com/liveblog/users/davewiner/2015/12/18/0667.html) "expensive security theater". He writes, "I have a couple dozen sites that are just archives of projects that were completed a long time ago. I'm one person. I don't need make-work projects, I like to create new stuff, I don't need to make Google or Mozilla or the EFF or Nieman Lab happy."

Winer is not alone. Anyone who has put in the effort to get HTTPS working on even one site knows that it can be a tremendous hassle. Indeed this is probably the biggest obstacle to widespread HTTPS adoption. It's hard. Ars has a tutorial that clocks in at tk words. The tutorial I used to get HTTPS working on my site was written by developer Eric Mill and is tk words. 

First you need to get a certificate, which is not free. There are certificate authorities who do not charge to issue certificates, the best known of these is probably StartSSL, but if you ever need to revoke your certificate for some reason there is a fee. In other words the certificates are only free if nothing ever goes wrong. If something does go wrong and you need to revoke a dozen or more sites it quickly gets expensive.

Once you have a certificate you have to install it and get your web server to serve it up properly. Provided you have a basic sys-admin's knowledge this isn't too hard, though tweaking it until you get a A+ grade on SSLLab's test can take many, many hours. I've been running my own site, building my own CMS and running servers on the web for over a decade an I can say without hesitation that getting HTTPS working on my site was the hardest thing I've done on the web.

There is hope on the horizon though. The EFF and Mozilla have partnered with some other big names to create Let's Encrypt, which offers free certificates -- yes, really free, no catches -- and a tool that makes installing and configuring them pretty simple. It's still (currently) a command line tool that requires basic sysadmin knowledge (and SSH access to your server) to use, but it makes getting HTTPS leaps and bounds easier than it was just a year ago.

Over the long run Let's Encrypt is hoping to partner with popular web hosts in such away that users looking to set up their own blog using popular CMS like WordPress get an HTTPS site up and running as easily as clicking a button. 

That day isn't quite here yet though and so the question Winer and others would like answered is simple: why? Why should we invest all this effort to encrypt websites that are just archived flat HTML pages?

Several years ago I wrote a piece on the then nascent effort to get HTTPS more widely adopted. At the time I wrote "For sites that don't have any reason to encrypt anything... HTTPS just doesn't make sense."

I was wrong. 

In 2010 when I wrote that the network of the web looked fairly benign (as Snowden's leaks of revelled, it was not, but most of us had no real way to know back then). Since that time the network has become hostile, incredibly hostile. 

The web has become a broad survellance tool for everyone from the NSA to Google to Verizon.

tk bit here on how HTTPS isn't going to help you if you're targetted by the NSA. What an crypted web does is force survelliance to be expensive and targeted rather than ceap and broad.

Winer calls out Google specifically and he's not the only one to do so. Google's motives for pushing an HTTPS web are because an HTTPS web is in Google's best interest. Google is very protective of its search algorithms and results. However, according to some sources Verizon and other ISP have been injecting code into HTTP connections to gather data about search results and what people are clicking. This data is then resold in backroom deals. 

Yes, Google's acting in its own best interests and Winer is right to question the motives of a company so massive it has the power to potentially control elections. However, in this case Google's interests are aligned with the web at large. Google doesn't want that data captured and sold, but remember that data is actually about you. It's your data first and foremost and even if you don't want to exist at all, you certainly don't want it bought and sold.



Which brings us to today. HTTPS is becoming more and more common, easier and easier for anyone to get up and running. what's the next step?

The next step is depricate the non-secure web. That is, turn HTTP into a second class citizen that, eventually, might be ignored all together.








For the individual user the network has become hostile, for companies like Google the network has also become hostile. 





You don't have to dive too deep into H

main motivation for HTTPS is authentication of the visited website and protection of the privacy and integrity of the exchanged data.





Much of the confusion comes from our tendency to conflate security and privacy. While security is often necessary for privacy, the security you have does not guarantee anything. For example, you can have a secure HTTPS connection to Google, but that doesn't actually mean anything for your overall privacy. Google can still collect information about you, track you with cookies and then be compelled to give that information to the government. It can also just sell it to the highest bidder. Security is not a guarantee of privacy.

All the users whose data has been compromised in any of the hundreds of major data leaks from Target, tk, tk, or tk was collected over HTTPS connection. Security is not privacy.

In the case of HTTPS the primary things that the "S" offers is protection against what's known as a Man in the Middle (MitM) attack. Imagine you're at a coffee shop chatting with what you think is your friend tk.  browsing tk for a tk. You decide to buy the tk. You're connected to tk, but someone else at the coffee shop (most likely wearing a dark hoodie and hunched furtively over a laptop if the press is to be believed) is watching you connect to tk. Hoodie can impersonate tk  

A MitM attack





###Broad questions:

How does HTTPS help users? 
great cannon attack 2015 

Does it stop nation state attacks by the NSA et al?
tls dns hijacking anti-virus super phish vulnerability -- fake root to inject ads. attacks go lower level cert flaws.

Does it protect user privacy, if so how? All the tracking cookies are still there. If the NSA wants them they just subpoena Google right?

It stops man in the middle attacks. How common are those? Does anyone have any data on that? Bogeyman, accessible metaphor, but practical use it's unlikely to happen.



---

###Cert flaws:

Verizon injecting code to reconstruct cookies. If they're willing to do that, what's to stop them from including compromised certs that allow them to still inject the code? They control the platfor, that's unbeatable from the security standpoint.

"Even if the browser, OS were under your control you have no control over what the web application is doing with your data. Not only could it be being shared with servers through third-party sub-requests, it can also be passed server-server to thousands of other entities  and often is. 

Link security != privacy. Privacy needs the rule of law not total secrecy."

https://lists.w3.org/Archives/Public/www-tag/2015Jan/0091.html

---
>
>   Also wondering whether, apropos the recent debates about moving to
> HTTPS, companies like Verizon would be able to MITM HTTPs traffic to
> play games like this. Seems to depend on the cert control provided by
> mobile browsers, and I'm concerned that in practice many of the
> browsers come from the ISPs, which supply the phones, which check the
> certs....
> 

This has been going on for ages. What's new is categorizing it as MitM
with all the "attack" connotation baggage that brings along with it, in
the use case where it's opted into. Or considering it in terms of mobile
Internet. Others have long called it a "business model". Sometimes it's
opted into by agreeing to a TOS, where I'd prefer opt-in based on users
having to configure browser settings for it, but I see where if that
was the business I was in, I'd think otherwise. Either way, I hesitate
to call it fraudulent outright.

https://lists.w3.org/Archives/Public/www-tag/2015Jan/0173.html

---

###technical details:

LetEncrypt is great, but it's still way beyond the capabilites of your average blogger installing wordpress (or more likely clicking a button to install wordpress). Even if it were a one-click process to create, install and configure a cert, how does the blogger even find out that this is something they need to do?

designed for helping servera admins, the no tech are using hosting services. it's getting easier. peole are becoming more dependent on hosting services.

Let's say I managed to figure all that out (which I have just for the record) who is going to renew my certs when I die? Or if I just stop caring/maintaining my site? 

you already need to have server patches, etc

Tim Berners Lee has called the move from http to https, "arguably a greater threat to the integrity for the web than anything else in its history." Given that URLs breaking, changing and disappearing is already a massive problem, and that this move WILL ABSOLUTELY MEAN MORE BROKEN SITES, how is that a win for the web?

On browser indicators, there have already been studies that show no one pays any attention to them: "We also found that the security certificate cue was not used by the participants to determine the legitimacy of the presented Websites." http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6454330

---

https://lists.w3.org/Archives/Public/www-tag/2015Jan/0080.html:

> Also wondering whether, apropos the recent debates about moving to HTTPS,
> companies like Verizon would be able to MITM HTTPs traffic to play games
> like this. Seems to depend on the cert control provided by mobile browsers,
> and I'm concerned that in practice many of the browsers come from the ISPs,
> which supply the phones, which check the certs....

A code-signed browser from a trustworthy source, consulting only its
own trust anchor store and/or enforcing key pinning and/or enforcing
Certificate Transparency, can generally enforce the guarantees of
HTTPS (which include stopping these cookie insertion attacks).

Of course, if the platform is under the control of someone other than
the owner, such as the carrier, the platform can subvert any
application at run-time.

That underscores the importance of getting one's platform from a
trustworthy vendor. But that problem is entirely outside of TAG's
scope.

HTTPS is what we can do. Buttressing the web PKI is what we can do. So
we do. Some companies with representatives on this list are also
trying to provide trustworthy platforms to run apps on, too. So we do.

Surely, you weren't hoping to use evidence of application-layer
attacks as a reason to not adopt effective application-layer security
techniques.

---

https://lists.w3.org/Archives/Public/www-tag/2015Jan/0083.html

On 1/16/2015 2:54 AM, Chris Palmer wrote:
> Surely, you weren't hoping to use evidence of application-layer
> attacks as a reason to not adopt effective application-layer security
> techniques.

No, but I think the TAG can play a useful role in documenting which of the 
problems we see "in the wild" the move to HTTPS will "solve", which it 
won't etc. Not everything we do as a community or that the TAG does can be 
100% effective, but IMO a key role of the TAG is to document tradeoffs, and 
to explain both the strengths and weaknesses of any proposed architectural 
change. In this case, many readers of TAG Findings will be less informed 
than the TAG. I think it will be helpful to clearly say: "This is what we 
can reasonably expect the move to do for HTTPS to do for you; these are 
some of the problems you might naively expect it to solve that it might not."

---

### Interesting arguments

https://lists.w3.org/Archives/Public/www-tag/2015Jan/0029.html

As I understand the statement, it means some people would prefer privacy and security, and others prefer convenience and entertainment.

This might just be projection. In some things, I am intensely protective of my privacy and security. In other matters, I couldn't care less about it. And while I'm far from infallible, I am regularly able to make reasonably informed decisions which demonstrate that I don't hold carefully to one or the other side of this apparent dichotomy.

...

FWIW I am not a fan of surveillance. But I note Russia is where Edward Snowden lives, for his own security.

---


If people want me to believe this is going to be handled competently, they need to stop pointing to vaporware as a solution, stop pointing to unusable crap as a solution, stop saying "Oh, it will work itself out." Because that's what I'm afraid of. Mozilla needs to acknowledge that at the moment, the TLS ecosystem is in absolute shambles, and switching to HTTPS-only is a terrible idea right now. Then I'll believe they're being realistic in their plans.


https://www.reddit.com/r/programming/comments/35vm9r/were_deprecating_http_and_its_going_to_be_okay/cr8lg3u

---

Thoughts on security:

Yves Lafon wrote:
> 
> And saying that the only solution for people with poor bandwidth is
> to get rid of their security is not really satisfying.
> 

Privacy. Again, sorry. But security, when required, makes me not care
about bandwidth or latency. If I'm after the balance in my checking
account, I don't care if logging in takes 30 seconds. What I don't need
is for every page I access to be that slow.


Potential future problems with tiered content :

In a post-net-neut world, everyone would have poor bandwidth and
latency, except when accessing the "fast lane", unless shared caching.
Sacrificing shared caching in the name of privacy which can't be
guaranteed at the application-protocol layer anyway, is not really
satisfying.

https://lists.w3.org/Archives/Public/www-tag/2015Jan/0031.html

---