11 ms·
How HTTPS Stops Attackers: What Every Web Dev Should Know
- jusob 13y agoGood 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).
- hartleybrody 13y agoAh good point, I sorta dashed off the title at the last minute. But the main focus of the article (and the whole point of HTTPS) is to make a secure end-to-end connection between a client and a server, not stop all attack vectors on a web server.
- YZF 13y agoWhen 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.
- rorrr2 13y agoI 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
- StavrosK 13y agoIt 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).
- sp332 13y agoIn 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.
- count 13y agoThere's a company called Bluecoat that makes appliances that are installed in many companies that do just this.
- YZF 13y agoIt 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.
- Ellipsis753 13y agoI had quite low expectations for what I would learn from this article but it was actually very good. I really liked the paint analogy and the simplified understandable maths. Does someone want to try it here? :P Lets use root 2 and a small private number. We can do mod 10 (so the last digit of 2^(your secret) is your public number). My public number would be 4. (My secret number is secret). I know this is kind of goofy but it could be fun?
- icedog 13y ago10 is not prime.
- Ellipsis753 13y agoDrat. I failed that quite badly. Yes, a prime number would be needed. If someone knows why a prime must be used or knows of something which explains why then I would be very interested to find out why this is.
- josephscott 13y ago"Because the TLS handshake occurs before the HTTP connection begins, there can be problems if there are multiple websites hosted on the same server, at the same IP address." This is why Server Name Indication ( SNI ) is so important. It allows multiple host names on a single IP address to support HTTPS. Once again, IE on Windows XP is the biggest problem here. Windows XP systems simply must use something besides Internet Explorer ( Chrome or Firefox would be good ).
- xxdesmus 13y agoGlobalSign has a pretty brilliant solution for dealing with Windows XP -- https://www.globalsign.com/cloud/multiple-ssl-certificates-single-ip-address.html https://www.globalsign.com/cloud/multiple-ssl-certificates-s...
- tzury 13y agoThe 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.
- antihero 13y agoIf you're hosting 10K domains and can't afford multiple IP addresses, you're doing something horribly wrong.
- tzury 13y agoThat's correct even for the first 25. I was talking about the meanings of maintaining multi-domain certs from scaling point of view.
- webdevsometimes 13y agoMaybe one IP is being used for non-monetary reasons - load balancing perhaps?
- blackprawn 13y agoWhat about proxied MITM attacks using a valid CA certificate for the proxy? And also, browsers are not the only HTTP clients out there. HTTPS I believe is a quite a mess as is cert validation and the CA Cert system in general. I view HTTPS as security-lite. I think we need something better.
- hartleybrody 13y agoThis 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 were just another router between networks. 2. Setup a "Man in the Middle Proxy" which creates/signs certificates for each site on the fly. Basically, the client thinks the proxy is the server, and the server thinks the proxy is the client. The only way this works though, is if the browser is instructed to trust certificates signed by the MitM proxy. So this works fine if you're setting up a proxy on your local dev machine, for example. But not for proxying HTTPS requests to actual users.
- sehrope 13y ago> 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 notice unless you are certificate pinning. The other big use for internal CAs is being able to issue SSL certs for internal apps without having to have them signed externally (both the inconvenience and $$$ involved).
- pampa 13y agoAND 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.
- karlgrz 13y agoThis was a really clear, concise overview. Just the right amount of explanation and clarity for me. Thanks!
- stephen_g 13y agoWhy 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...
- pbhjpbhj 13y agoIs 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.
- stephen_g 13y agoOf 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 https://news.ycombinator.com/item?id=6102983
- mountaineer 13y agoIn 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?
- stephen_g 13y agoYes, 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.html https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...
- YZF 13y agoSymmetric-key ciphers aren't used because they "save a round trip". They're used because they're much faster. One could use a public key encryption system to encrypt the entire session between two parties (e.g. RSA) but AES is much faster than RSA.
- oakenshield 13y agoSpeed is one concern but far from the main reason. You couldn't use a typical-length RSA key to encrypt a large chunk of data because there's a max input size for any given RSA key size. Standard block/stream cipher modes of operation are defined only for symmetric key ciphers.
- dspillett 13y agoYou can certainly use RSA as a block cypher, you are just limited in the size of the blocks.
- YZF 13y agoThe max input size is for one message. It's effectively the "block size" for RSA. You can send multiple messages using a single RSA key (and in fact pretty much everyone does that, otherwise you'd need a new public key for every message). RSA is a complete crypto system, you don't need any additional ciphers. You do need randomiziation (e.g. random padding).
- YZF 13y agoFor the sake of completeness, one such construction where RSA is used as a cipher is OAEP (Optimal Asymmetric Encryption Padding). Beyond being slow it has some other inefficiencies but that's another story.
- lvh 13y agoI'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 to be particularly related. - The symmetric system isn't more efficient because of round-trips. (I'm also not sure which round trips it saves on.) Also (and I made the same mistake in my talk...), yes, explaining DH is important, but now it kind of sounds like in TLS both sides figure out the master secret using DH (and, in your talk, specifically, regular DH, not EC-based DH), when in reality that depends on the ciphersuite, and the vast majority of TLS connections don't work that way. From what I understand to be most TLS configurations in the wild, the pre-master secret is encrypted using the server's public key. (RFC 5246: 7.4.7.1, 8.1.1) Finally, a bit of a plug, but... If you're interested in the build up, my PyCon 2013 talk "Crypto 101" starts from XOR and ends with TLS in 45 minutes. It mostly goes into a bit more detail about thinks like block and stream ciphers. I'm hoping to eventually turn this into a book. (If you're interested, my e-mail's in my profile.)
- CrimsonVoid 13y agoI 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.
- lvh 13y agoAwesome! 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.
- lvh 13y agoSince 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 https://www.youtube.com/watch?v=3rmCGsCYJF8
- mikerg87 13y agoThe 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 ?
- lotsofcows 13y agoIf the request and response are encrypted, how does the cache know what to cache?
- mikerg87 13y agoAt 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.
- lotsofcows 13y agoAh, I see. Yeah, I don't think client side caching is affected. Can't think of a reason it should be.
- area51org 13y agoI 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-does-ssl-impose http://stackoverflow.com/questions/548029/how-much-overhead-...
- mncolinlee 13y agoThis article leads me to wonder. Has the US Government ever requested the master private keys for the main certificate authorities, such as Verisign? It actually makes sense in a criminal investigation to spoof a real site in order to phish for passwords or the personal information of criminals. A similar method was used before to get cable thieves to call a phone number on the screen thinking they were giving their information to win a free item. However, having the capability to impersonate any company, group, or individual has an enormous potential for abuse.
- timus 13y agovery informative .. thank you ..!