How HTTPS Stops Attackers: What Every Web Dev Should Know • Hacker News Board

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

#21

Post by rorrr2 » Thu, Jul 25, 2013, 10:16 AM UTC

YZF wrote: post #14

jusob wrote: post #2

Good read about HTTPS, but very bad title. HTTPS does NOT stop attackers. It does stop data sniffing on wirelress network, but does not prevent any server-side attack (XSS, SQL Injection, an flaw in the web application).

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

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

#22

Post by tzury » Thu, Jul 25, 2013, 10:26 AM UTC

antihero wrote: post #16

tzury wrote: post #12

Earlier quoted context omitted.

The fallback is "multi-domain certificate", which means, if you host 10K domains, your server will send a certificate which contains 10K certificates within (a very large chunk), before anything can start. This solution is not scaleable obviously.

If you're hosting 10K domains and can't afford multiple IP addresses, you're doing something horribly wrong.

That's correct even for the first 25. I was talking about the meanings of maintaining multi-domain certs from scaling point of view.

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

#23

Post by mikerg87 » Thu, Jul 25, 2013, 10:28 AM UTC

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 ?

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

#24

Post by lotsofcows » Thu, Jul 25, 2013, 10:38 AM UTC

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?

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

#25

Post by pampa » Thu, Jul 25, 2013, 10:41 AM UTC

sehrope wrote: post #13

hartleybrody wrote: post #8

Earlier quoted context omitted.

This is pretty much what I was trying to see if we could do: proxy HTTPS requests to another site through our server. When proxies are involved with HTTPS, there are really two options: 1. The client sends a CONNECT request (instead of GET) which instructs the proxy to open up a secure tunnel with the remote server. In this situation, the proxy steps out of the way and simply shuffles bits back and forth, as if it we…

> But not for proxying HTTPS requests to actual users. Proxying everything, including HTTPS traffic, is not uncommon for internal proxies at corporations. Since they control the desktop infrastructure a lot of companies install an internal CA as trusted root. This trusted root can then masquerade as any website it wants since it can sign any certificate it generates on the fly. As a regular user you wouldn't even not…

AND because of the inconvenience and $$$ involved a lot of applications use a self signed cert and just skip checking the validity of the CA. I have written a few apps like that myself, so I suppose it is a common pattern.

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

#26

Post by StavrosK » Thu, Jul 25, 2013, 11:27 AM UTC

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 does prevent the vast majority of attacks. The only attacks it doesn't prevent when your CA signs the MITM's certificate, or when your browser trusts it itself (which is what happened in Nokia's case).

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

#27

Post by CrimsonVoid » Thu, Jul 25, 2013, 11:47 AM UTC

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.

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

#28

Post by webdevsometimes » Thu, Jul 25, 2013, 1:14 PM UTC

antihero wrote: post #16

tzury wrote: post #12

Earlier quoted context omitted.

The fallback is "multi-domain certificate", which means, if you host 10K domains, your server will send a certificate which contains 10K certificates within (a very large chunk), before anything can start. This solution is not scaleable obviously.

If you're hosting 10K domains and can't afford multiple IP addresses, you're doing something horribly wrong.

Maybe one IP is being used for non-monetary reasons - load balancing perhaps?

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

#29

Post by area51org » Thu, Jul 25, 2013, 1:28 PM UTC

I like this article, and found his explanations surprisingly clear.

One nitpick: SSL doesn't really impose much bandwidth overhead. http://stackoverflow.com/questions/548029/how-much-overhead-...

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

#30

Post by pbhjpbhj » Thu, Jul 25, 2013, 1:34 PM UTC

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.