summaryrefslogtreecommitdiff
path: root/https.txt
diff options
context:
space:
mode:
authorluxagraf <sng@luxagraf.net>2016-02-21 09:36:43 -0500
committerluxagraf <sng@luxagraf.net>2016-02-21 09:36:43 -0500
commita42e05b6c969f81ce75bc6a2892a233d984300dc (patch)
tree6bac8695475a6c97f93cbaa0549ec9336796f0c6 /https.txt
parent55d7d7d1cf0ebf2188ad8d86b232cc38d1d4fea6 (diff)
added interview notes and https piece
Diffstat (limited to 'https.txt')
-rw-r--r--https.txt176
1 files changed, 176 insertions, 0 deletions
diff --git a/https.txt b/https.txt
new file mode 100644
index 0000000..0698a8c
--- /dev/null
+++ b/https.txt
@@ -0,0 +1,176 @@
+Google, Mozilla, the EFF and tk are and have been pushing for websites to adopt HTTPS.
+
+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
+
+---