Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How HTTPS Stops Attackers: What Every Web Dev Should Know

blog.hartleybrody.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: How HTTPS Stops Attackers: What Every Web Dev Should Know

#31

Post by sp332 »

rorrr2 wrote: post #21
YZF wrote: post #14

Earlier quoted context omitted.

When properly applied it stops sniffing the wire as well (i.e. anywhere in the path) and man-in-the middle attacks and any active attack against the encryption. Obviously there are other types of attacks that are unrelated to the "cryptographic" security but that's a different story.

I thought HTTPS doesn't prevent MITM attacks. > In 2013, the Nokia's Xpress Browser was revealed to be decrypting HTTPS traffic on Nokia's proxy servers, giving the company clear text access to its customers' encrypted browser traffic. Nokia responded by saying that the content was not stored permanently, and that the company had organizational and technical measures to prevent access to private information

In Nokia's case, the browser trusted Nokia's server certificate and that's how they were doing MITM. The same could be done if your employer installs a client certificate on your laptop.

Re: How HTTPS Stops Attackers: What Every Web Dev Should Know

#32

Post by count »

rorrr2 wrote: post #21
YZF wrote: post #14

Earlier quoted context omitted.

When properly applied it stops sniffing the wire as well (i.e. anywhere in the path) and man-in-the middle attacks and any active attack against the encryption. Obviously there are other types of attacks that are unrelated to the "cryptographic" security but that's a different story.

I thought HTTPS doesn't prevent MITM attacks. > In 2013, the Nokia's Xpress Browser was revealed to be decrypting HTTPS traffic on Nokia's proxy servers, giving the company clear text access to its customers' encrypted browser traffic. Nokia responded by saying that the content was not stored permanently, and that the company had organizational and technical measures to prevent access to private information

There's a company called Bluecoat that makes appliances that are installed in many companies that do just this.

Re: How HTTPS Stops Attackers: What Every Web Dev Should Know

#33

Post by mikerg87 »

lotsofcows wrote: post #24
mikerg87 wrote: post #23

The article states that "Security breaks caching" but doesn't seem to give anything on the topic. Would a kind soukd elaborate or point me to tips on how to improve performance under these conditions ?

If the request and response are encrypted, how does the cache know what to cache?

At some point the browser must decode the content to render it on the display. So this decrypted content on the client machine could be cached, which leads to my confusion on the subject. I clearly don't understand something here.

Re: How HTTPS Stops Attackers: What Every Web Dev Should Know

#34

Post by lvh »

CrimsonVoid wrote: post #27
lvh wrote: post #20

I'm wondering about this paragraph: --- This public key exchange only needs to happen once per session, the first time the client and server connect. Once they’ve agreed on a shared secret, the client and server communicate using a symmetric-key crypto system which is much more efficient to communicate on since it saves an extra round-trip each exchange. --- Two points: - The first and second sentences don't appear t…

I absolutely loved your talk; not only is it pretty informative but also entertaining, and found myself rewatching it just because. I think your talk gave me enough knowledge of crypto to take another go at Stanford's "Cryptography I" class. So thanks and I'll look out for your book.

Awesome! Always glad to hear from a happy customer :)

Is there something in particular that you would like more of or perhaps to stay the same? Humor is good, I suppose?

Obviously, a book lets me go in more detail, but I'm disinclined to take that too far. The entire beauty of Crypto 101 is that it doesn't go into detail. Right now I'm mostly just marking sections that you could skip if you want to.

Re: How HTTPS Stops Attackers: What Every Web Dev Should Know

#35

Post by mountaineer »

stephen_g wrote: post #10

Why don't they mention HSTS? Seriously a very important safeguard against HTTPS stripping. Apart from that, my idea of what every web dev should know about HTTPS is use HTTPS for everything . The performance reduction is minimal and far less important than the security gain...

In general I agree that you should err on the safe side and do HTTPS everywhere. But, until you profile your site with/without HTTPS how do you know performance reduction is minimal? Do you have evidence to support such a blanket argument?

Re: How HTTPS Stops Attackers: What Every Web Dev Should Know

#36

Post by lvh »

lvh wrote: post #20

I'm wondering about this paragraph: --- This public key exchange only needs to happen once per session, the first time the client and server connect. Once they’ve agreed on a shared secret, the client and server communicate using a symmetric-key crypto system which is much more efficient to communicate on since it saves an extra round-trip each exchange. --- Two points: - The first and second sentences don't appear t…

Since I can't seem to edit my comment. I figured it would be useful to provide a link to the talk I'm referencing: https://www.youtube.com/watch?v=3rmCGsCYJF8

Re: How HTTPS Stops Attackers: What Every Web Dev Should Know

#37

Post by stephen_g »

mountaineer wrote: post #35
stephen_g wrote: post #10

Why don't they mention HSTS? Seriously a very important safeguard against HTTPS stripping. Apart from that, my idea of what every web dev should know about HTTPS is use HTTPS for everything . The performance reduction is minimal and far less important than the security gain...

In general I agree that you should err on the safe side and do HTTPS everywhere. But, until you profile your site with/without HTTPS how do you know performance reduction is minimal? Do you have evidence to support such a blanket argument?

Yes, of course I have evidence. Refer to Google's experience in 2010 when they switched Gmail to HTTPS by default [1]:

> On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead.

> If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.

1. https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...

Re: How HTTPS Stops Attackers: What Every Web Dev Should Know

#38

Post by stephen_g »

pbhjpbhj wrote: post #30
stephen_g wrote: post #10

Why don't they mention HSTS? Seriously a very important safeguard against HTTPS stripping. Apart from that, my idea of what every web dev should know about HTTPS is use HTTPS for everything . The performance reduction is minimal and far less important than the security gain...

Is the performance reduction of the entire web with https really "minimal"? You've got extra overhead to setup the connection, extra processing to handle the encryption, no intermediate caching AFAICT. Clearly that has some impact - I'd expect it to be significant.

Of course it has some impact. But it's not significant at all. Take a look at the link in the other comment: https://news.ycombinator.com/item?id=6102983

Re: How HTTPS Stops Attackers: What Every Web Dev Should Know

#39

Post by lotsofcows »

mikerg87 wrote: post #33
lotsofcows wrote: post #24

Earlier quoted context omitted.

If the request and response are encrypted, how does the cache know what to cache?

At some point the browser must decode the content to render it on the display. So this decrypted content on the client machine could be cached, which leads to my confusion on the subject. I clearly don't understand something here.

Ah, I see. Yeah, I don't think client side caching is affected. Can't think of a reason it should be.

Re: How HTTPS Stops Attackers: What Every Web Dev Should Know

#40

Post by YZF »

rorrr2 wrote: post #21
YZF wrote: post #14

Earlier quoted context omitted.

When properly applied it stops sniffing the wire as well (i.e. anywhere in the path) and man-in-the middle attacks and any active attack against the encryption. Obviously there are other types of attacks that are unrelated to the "cryptographic" security but that's a different story.

I thought HTTPS doesn't prevent MITM attacks. > In 2013, the Nokia's Xpress Browser was revealed to be decrypting HTTPS traffic on Nokia's proxy servers, giving the company clear text access to its customers' encrypted browser traffic. Nokia responded by saying that the content was not stored permanently, and that the company had organizational and technical measures to prevent access to private information

It certainly does. A cryptographic system that does not is useless. In the most basic sense, if you can't trust anyone you can't know if you're talking to a man-in-the-middle pretending to be someone else. TLS provides a mechanism for converting trust in a CA to trust that you're talking to the right party (who presented the certificate). If someone has a cert you accept and he's not the party you want to talk to that's not really TLS's fault and there's actually very little you can do about that. There are practical considerations as well but from a theoretical perspective it's secure.
Post reply on HN