9 ms·

HTTPS is more secure, so why isn't the Web using it?

84 points by zoowar 16y ago

kennet 16y ago
I have a silly, fictional view of the future: That every website will be HTTPS by default, and instead of Firefox/Chrome/etc using a "green" bar to tell a secure website, it will not say anything, but will display big red warnings when a website is not secure.
- jedsmith 16y ago
  And we'll all have muscle memory to add the exception through the browser's four-step "I know what I'm doing" UI.
  - drzaiusapelord 16y ago
    In Chrome and IE its one or two clicks. I don't know why people tolerate Firefox's silly "ZOMG THIS SSL CERT MIGHT BE WRONG" 90-click UI. Joe Averge is still going to run through the clicks. Badgering the user with more prompts has been shown to not increase security and only frustrate power users.
- drzaiusapelord 16y ago
  The problem is that there aren't enough IPv4 IP address for this. Each SSL cert requires an IP address. So if you have 200 sites on one virtual setup with one IP, only one of them can have the SSL. The connection needs to be established before Apache or IIS can be told what site to serve. Maybe v6 will solve this, but right now you simply cannot do this. Or maybe the spec can be changed somehow (ask for host first then start SSL handshake?).
  - duskwuff 16y ago
    > Or maybe the spec can be changed somehow (ask for host first then start SSL handshake?). SNI does exactly this. Sadly, MSIE doesn't support it under Windows XP (and earlier), so we have to live without it for a while longer.
benjoffe 16y ago
> You wouldn't write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection that's essentially what you're doing. I'll be honest, I didn't read any more of the article after this totally false statement in the intro. Facebook and Twitter both use https for login (they are http pages that submit to a https endpoint that redirect to http, that way https is used for authentication but never appears in the url).
- djjose 16y ago
  True, but it's not obvious to non-techies (hence the article). I was curious how FB did logins when we were creating our API and site since I couldn't fathom them sending l/p's without https. A long look at their source on the homepage is really all it took to guess what they did (a guess, I could still be wrong). After a good deal of painful eyestrain I noticed they seemed to be using their internal APIs via JS over https for authentication. I wonder how many "non-https" sites also do this. I'd still wager a good deal of sites still send authentication over plain ol' http though. Is the lag for authentication purposes really that bad? Anyone have any hard metrics?
- watchandwait 16y ago
  Yeah but even with https login, if a site also serves regular http pages, cookies with session credentials are still visible (on open networks) and the session can be hijacked.
- kinofcain 16y ago
  Sort of. Twitter and Facebook still serve their home pages as HTTP and provide a login form that posts over HTTPS. The problem is that I can do a MITM attack on the unsecured home page and put my own script in there that siphons off the user's password when they click the submit button. So the HTTPS-posting form prevents the eavesdropping case, but not the man-in-the-middle case. That's how the Tunisian government was harvesting their citizen's facebook logins: http://www.thehackernews.com/2011/03/exposure-how-does-tunisian-government.html http://www.thehackernews.com/2011/03/exposure-how-does-tunis...
bitskits 16y ago
I have a feeling it has more to do with the sharing of cookies and tracking code than anything else. Once everything is https:// https://, marketers aren't able to share information across sites, and although the internet is made of cats, those cats need their money.
DrStalker 16y ago
If browsers would be happy to allow users to a site with a self-signed SSL certificate, which is far more secure than HTTP, then I'd be happy to put in the extra time and effort to ensure 100% of communications occured over HTTPS. Until then it's extra time, effort and cost to offer something that most users do not understand and do not care about.
- mukyu 16y ago
  A self-signed cert provides effectively zero protection. You have no guarantee of the identity of the site and there is no confidentiality in your traffic. Key continuity (the only assurance you have that the cert might be legit) is not effective on the web, where you are likely to interact with hundreds of unknown hosts. If browsers do not throw big warnings at self-signed certs it is trivial to impersonate even sites that do have real certificates. The user sees a lock icon and thinks they are secure, but they are sending their credit card to someone other than Amazon.com. This is slightly fixed by EV certs, but there is still a large user training issue.
  - jedsmith 16y ago
    > A self-signed cert provides effectively zero protection. From the other end. I had this debate with someone in person, and they tried to tell me that since you cannot trust the other end with a self-signed there is no point in protecting your traffic from eavesdroppers on the open AP. That makes no sense to me, but he was passionate enough about it that I let it go. He never could tell me why, so I invite a more learned HNer to complete his argument for him and persuade me. My take: There's a difference between identity and encryption, and I think warning users about a site that wants encryption but doesn't necessarily want or need identity is a bigger user-training mistake than anything else browsers have ever done. Perhaps the lock was the problem there; in that case, if I offer a self-signed certificate, perhaps the better UI experience would be to inform the user in that "Page Info" that their connection is encrypted, but they have no idea if the other end is who they say they are -- and don't bless the page with a lock, bar, anything. The entire construction of https:// https:// needing to imply both encryption and identity doesn't make sense to me, as I see them as distinct concepts. One does not necessarily imply the other, but browsers make it so. Maybe this is inherent to SSL/TLS itself and I'm the off-base one, but logically it makes sense to me.
mopoke 16y ago
> Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn't work with virtual hosts. That's a bit confusing. They mean when multiple sites share the same public IP. You can run SSL on a "virtual host" (i.e. a host running as a VM rather than on bare metal). Also not mentioned is the general increase in server load by having to encrypt/decrypt all traffic. (or the additional cost of investing in a dedicated layer to do that for you).
- jedsmith 16y ago
  > "virtual host" (i.e. a host running as a VM rather than on bare metal). That isn't what virtual host means, particularly not here. Your "they mean ___" is exactly what virtual host means. http://en.wikipedia.org/wiki/Virtual_hosting http://en.wikipedia.org/wiki/Virtual_hosting > Also not mentioned is the general increase in server load by having to encrypt/decrypt all traffic. Because it's fairly negligible, especially with OpenSSL able to take advantage of AES-NI and equivalents. Most of the hit you see is setting up a connection. You can move SSL off your app stack and onto load balancers, too, and it's wise to do so.
- streeter 16y ago
  It is actually possible to serve multiple virtual hosts from the same IP (http://en.wikipedia.org/wiki/Server_Name_Indication#The_fix http://en.wikipedia.org/wiki/Server_Name_Indication#The_fix). The first technique is called Sever Name Indication, which is a way to specify a virtual host with TLS (https) negotiations by sending the virtual domain as part of the TLS negotiation The second method is a specification that introduces the subjectAltName field which allows one cert to be used across multiple subdomains (for things like wildcarding). This would make it really easy to do organization-based subdomains with TLS encryption. There are limits to which browsers and which servers can do it. It requires IE7 and up (not on XP though), and basically all recent versions of other browsers. Edit: noted that IE on XP doesn't work.
  - duskwuff 16y ago
    SNI doesn't work in IE7 (or IE8) if you're running Windows XP. This ends up leaving a sizable chunk of users unable to use it.
listrophy 16y ago
From the article, it's not so much the TLS protocol that allows SSL on virtual hosts, it's specifically the Server Name Indication (SNI) TLS extension. And every major browser version supports SNI except IE6 (arguably not major anymore) and any IE on XP (except maybe IE9?).
- jedsmith 16y ago
  IE9 will never run on XP, so you're right, just not in a way you expect.
  - listrophy 16y ago
    I thought that might be the case, but I figured I had already hit my limit on parenthetical phrases, so I didn't bother investigating.
tghw 16y ago
The real problem, according to Lafon, is that with HTTPS you lose the ability to cache. I'm fairly certain this is false, unless they're talking about proxy caching. Normal browser caching works equally well in HTTPS as it does in HTTP.
- jedsmith 16y ago
  The leading browsers were fairly stubborn on caching SSL resources for a while -- specifically to disk -- but (I think) most of them now obey the magic words: Cache-control: public Some data here: http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https http://stackoverflow.com/questions/174348/will-web-browsers-... I'm interested in what the state of this is, myself, but I know that one of IE 9's improvements was HTTPS conditional requests.
- justinludwig 16y ago
  > unless they're talking about proxy caching I'm fairly certain that's what he's talking about. A) He's Yves Lafon, and B) when you're talking web architecture, you care very much about what intermediaries can do.
kinofcain 16y ago
What I find as slightly amusing is that the major web browsers will throw up all sorts of fancy, scary warning messages if you're hitting a site with an expired or invalid certificate, but they don't say a darn thing when you hit a site over http. I understand that lying about your encryption is potentially a bigger deal than not having any at all, but still.
eapen 16y ago
Disappointed to see that this author doesn't really understand the issue he is writing about. The Firesheep tool would actually pick the cookies sent over HTTP rather than the username/password which was sent securely (in most cases). Also, as others have mentioned, it is possible to have an SSL cert installed on Virtual hosts. Dreamhost offers an option for as little as around $3-4 a month to have an SSL cert for a site. Sometimes, I wish I could downvote an article on HN.
nate 16y ago
I was doing some load testing on a new project of ours and noticed that I couldn't break 50-60 reqs per second sending all the requests through stunnel-haproxy or apache-haproxy to a cluster of app servers that should have handled about 200ish reqs per second. This wasn't a problem if the traffic wasn't encrypted. Didn't seem like a CPU bottleneck with the machine doing the load test measurements either. So I did some digging. And noticed that https://encrypted.google.com https://encrypted.google.com uses RC4_128 as a cipher. You know what Bank of America uses too? RC4_128. RC4 happens to be a much faster cipher. RC4 has gotten some bad press as it was used in WEP encryption and was cracked. But I believe it was because their RC4 implementation had a flaw rather than RC4 at 128 bis being a terrible choice for encryption? I'm not positive and would love to hear your input. I switched our load balancer to make sure we were using RC4_128 instead of AES_256, and bam I had 3-4 times more throughput of encrypted requests going through just fine.
- mukyu 16y ago
  The attacks used against RC4 as used in WEP are not applicable to RC4 as used in TLS connections. If you do not use related keys and discard at least the first 256 bytes, RC4 is fine. It is not that they implemented RC4 incorrectly, but that they did not account for its known weaknesses.
yason 16y ago
I'm strongly in favor of encrypting the channel even without signed certificates. A self-signing certificate doesn't authenticate the session but it can be used to later verify that the other end hasn't changed. It's much like bumping onto someone at the gym frequently but not really knowing their name or who they are. You can still trust that he's the same guy, sans having had a facial plastic surgery. Sending passwords over plaintext http is just stupid. To mount a man-in-the-middle attack you actually have to do something and position yourself between the two ends, not just listen to the passing network traffic. So, you might log on to Twitter at home (a relatively safe connection) and receive their public key and then use that to communicate with Twitter again later in public wifis or among middlemen at the airport. The browser would refuse to connect if the key doesn't match, much like ssh will complain if the host key fingerprint has changed (and require you to do manual purging of your known_hosts file). Gmail is the only one where you can tap "Always use https" on. To Facebook you can connect with https://facebook.com https://facebook.com but I don't know whether any auxiliary or Ajax/XMLRPC connections will use that.
- chrisbolt 16y ago
  I'm strongly in favor of encrypting the channel even without signed certificates. A self-signing certificate doesn't authenticate the session but it can be used to later verify that the other end hasn't changed. Because it's comforting to know that you handed over your private information to a man-in-the-middle and nobody else.
  - pyre 16y ago
    Errr... Are we advocating HTTPS everywhere? Or just when it's time to transfer private information? When I want to read an essay on some random website, to I need to now that the website owner is who they say that they are? Isn't self-signed HTTPS better than just plain old HTTP? Or is it better that we only use HTTPS for a select few sites that aren't self-signed and HTTP everywhere else?
    - chrisbolt 16y ago
      If you're not transferring private information, why does it matter if it's encrypted? Either you care if someone can eavesdrop or you don't.
known 16y ago
HTTPS - HTTP = 3 Seconds
fierarul 16y ago
'The web' isn't using HTTPS since SSL is a nice yearly 'tax' on the domain owner. It seems to me we have a nice centralized monopoly here with the existing Certificate Authorities (most US-centric) for something as decentralized as the internet. Why can't the domain name registrar give me a SSL cert for free? I mean, if I did buy a domain name, and I'm able to change the records, it's pretty clear I own the thing. Certificate info should just be a DNS record imho. Regarding identity checks, there are other stupidities I see here: for example, my company has to send monthly/yearly papers to the government entities (some of which get publishes into some official government papers). Why can't I publish my public key there? I mean, if anything, it's very bureaucratic to do anything involving public institutions so each paper is stamped, checked, etc. I would trust more a local clerk to check for identity then some US guy that has never in his life actually seen a deed of incorporation for a Romanian entity. So, yeah, I would love to have my site with HTTPS and to sign all my JARs and emails but until this becomes more sane or my customers actually start demanding it, I'm not going to waste money on that.
- bsdbuddy 16y ago
  Although I absolutely agree with your whole comment, I would just like to add one point. If you doing online business, and successfully, the yearly charge shouldn't be such an issue. However, for non-profit websites its absolutely out of the question. I'm curious - as your customers aren't demanding SSL what industry are you in?
  - fierarul 16y ago
    Well, the yearly charge isn't such an issue, but I cringe knowing I could pay a small server for an year of uptime with the money I pay for an SSL cert, which is essentially an official stamp of a member of the CA oligarchy. I mostly do contract work so I don't need SSL on my front-facing sites. We do use sites that have SSL to send deliverables and such, but I just pay for their service, not for the cert itself. Internally we've also used self-signed certs, our own CA or just SSH port forwarding. As an industry we should move towards encription but away from the current CA model. Somehow everybody portrays it as if it's the same thing.
kogir 16y ago
Why can't I add my site's certificate as a DNS record, use DNSSEC and be done? I don't want to give Symantec (owner of Verisign) money or trust to do something I can easily do myself.
- dchest 16y ago
  That's what djb's CurveCP is trying to do (http://curvecp.org/ http://curvecp.org/) (except with DNSCurve and custom protocols)
- asharp 16y ago
  because DNSSEC isn't required. As an example, if i mitm your dhcp request, i insert myself in as your dns server and gateway and i just say that DNSSEC isn't enabled for this domain. You have to trust me, and I can give you a MITM'd page. Similarly dnssec uses a very similar model. You need somebody to sign that your record is valid which is roughly the same as somebody signing your certificate as valid. They are both a chain of trust, they just differ slightly in implementation. I do agree with you that using dnssec makes more sense then our current system.
jeza 16y ago
Living in Australia, I can tell you the main reason caching is so important is because our main telco decided to charge by megabytes of usage. Back in the days when most of us were stuck on dialup, they were charging $0.18 a megabyte. At least the slow speeds limited the damage, though downloading a 600MB would still have cost a ridiculous $108. Meanwhile the rest of the world hadn't even though of charing such tariffs for internet usage. Of course once you have one company setting the standard then their competitors all follow suite. While things have improved tremendously since then, broadband plans are still based around download and sometimes even upload usage. At least now you're looking at something more reasonable like $50/month for 50 gigabytes a month of included download usage. So originally caching would actually save you serious money (unfortunately ISPs rarely passed on these savings to customers if they used their proxy server). Though nowadays it's less important as long as the websites you visit are responsive. Granted you're always going to have some kind of client side cache.
PHPAdam 16y ago
Its due to SSL Tax should be included free with every IP. IMHO.

84 points by zoowar 16y ago

I have a silly, fictional view of the future: That every website will be HTTPS by default, and instead of Firefox/Chrome/etc using a "green" bar to tell a secure website, it will not say anything, but will display big red warnings when a website is not secure.

jedsmith 16y ago
And we'll all have muscle memory to add the exception through the browser's four-step "I know what I'm doing" UI.
- drzaiusapelord 16y ago
  In Chrome and IE its one or two clicks. I don't know why people tolerate Firefox's silly "ZOMG THIS SSL CERT MIGHT BE WRONG" 90-click UI. Joe Averge is still going to run through the clicks. Badgering the user with more prompts has been shown to not increase security and only frustrate power users.
drzaiusapelord 16y ago
The problem is that there aren't enough IPv4 IP address for this. Each SSL cert requires an IP address. So if you have 200 sites on one virtual setup with one IP, only one of them can have the SSL. The connection needs to be established before Apache or IIS can be told what site to serve. Maybe v6 will solve this, but right now you simply cannot do this. Or maybe the spec can be changed somehow (ask for host first then start SSL handshake?).
- duskwuff 16y ago
  > Or maybe the spec can be changed somehow (ask for host first then start SSL handshake?). SNI does exactly this. Sadly, MSIE doesn't support it under Windows XP (and earlier), so we have to live without it for a while longer.

benjoffe 16y ago

> You wouldn't write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection that's essentially what you're doing. I'll be honest, I didn't read any more of the article after this totally false statement in the intro. Facebook and Twitter both use https for login (they are http pages that submit to a https endpoint that redirect to http, that way https is used for authentication but never appears in the url).

djjose 16y ago
True, but it's not obvious to non-techies (hence the article). I was curious how FB did logins when we were creating our API and site since I couldn't fathom them sending l/p's without https. A long look at their source on the homepage is really all it took to guess what they did (a guess, I could still be wrong). After a good deal of painful eyestrain I noticed they seemed to be using their internal APIs via JS over https for authentication. I wonder how many "non-https" sites also do this. I'd still wager a good deal of sites still send authentication over plain ol' http though. Is the lag for authentication purposes really that bad? Anyone have any hard metrics?
watchandwait 16y ago
Yeah but even with https login, if a site also serves regular http pages, cookies with session credentials are still visible (on open networks) and the session can be hijacked.
kinofcain 16y ago
Sort of. Twitter and Facebook still serve their home pages as HTTP and provide a login form that posts over HTTPS. The problem is that I can do a MITM attack on the unsecured home page and put my own script in there that siphons off the user's password when they click the submit button. So the HTTPS-posting form prevents the eavesdropping case, but not the man-in-the-middle case. That's how the Tunisian government was harvesting their citizen's facebook logins: http://www.thehackernews.com/2011/03/exposure-how-does-tunisian-government.html http://www.thehackernews.com/2011/03/exposure-how-does-tunis...

bitskits 16y ago

I have a feeling it has more to do with the sharing of cookies and tracking code than anything else. Once everything is https:// https://, marketers aren't able to share information across sites, and although the internet is made of cats, those cats need their money.

DrStalker 16y ago

If browsers would be happy to allow users to a site with a self-signed SSL certificate, which is far more secure than HTTP, then I'd be happy to put in the extra time and effort to ensure 100% of communications occured over HTTPS. Until then it's extra time, effort and cost to offer something that most users do not understand and do not care about.

mukyu 16y ago
A self-signed cert provides effectively zero protection. You have no guarantee of the identity of the site and there is no confidentiality in your traffic. Key continuity (the only assurance you have that the cert might be legit) is not effective on the web, where you are likely to interact with hundreds of unknown hosts. If browsers do not throw big warnings at self-signed certs it is trivial to impersonate even sites that do have real certificates. The user sees a lock icon and thinks they are secure, but they are sending their credit card to someone other than Amazon.com. This is slightly fixed by EV certs, but there is still a large user training issue.
- jedsmith 16y ago
  > A self-signed cert provides effectively zero protection. From the other end. I had this debate with someone in person, and they tried to tell me that since you cannot trust the other end with a self-signed there is no point in protecting your traffic from eavesdroppers on the open AP. That makes no sense to me, but he was passionate enough about it that I let it go. He never could tell me why, so I invite a more learned HNer to complete his argument for him and persuade me. My take: There's a difference between identity and encryption, and I think warning users about a site that wants encryption but doesn't necessarily want or need identity is a bigger user-training mistake than anything else browsers have ever done. Perhaps the lock was the problem there; in that case, if I offer a self-signed certificate, perhaps the better UI experience would be to inform the user in that "Page Info" that their connection is encrypted, but they have no idea if the other end is who they say they are -- and don't bless the page with a lock, bar, anything. The entire construction of https:// https:// needing to imply both encryption and identity doesn't make sense to me, as I see them as distinct concepts. One does not necessarily imply the other, but browsers make it so. Maybe this is inherent to SSL/TLS itself and I'm the off-base one, but logically it makes sense to me.

mopoke 16y ago

> Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn't work with virtual hosts. That's a bit confusing. They mean when multiple sites share the same public IP. You can run SSL on a "virtual host" (i.e. a host running as a VM rather than on bare metal). Also not mentioned is the general increase in server load by having to encrypt/decrypt all traffic. (or the additional cost of investing in a dedicated layer to do that for you).

jedsmith 16y ago
> "virtual host" (i.e. a host running as a VM rather than on bare metal). That isn't what virtual host means, particularly not here. Your "they mean ___" is exactly what virtual host means. http://en.wikipedia.org/wiki/Virtual_hosting http://en.wikipedia.org/wiki/Virtual_hosting > Also not mentioned is the general increase in server load by having to encrypt/decrypt all traffic. Because it's fairly negligible, especially with OpenSSL able to take advantage of AES-NI and equivalents. Most of the hit you see is setting up a connection. You can move SSL off your app stack and onto load balancers, too, and it's wise to do so.
streeter 16y ago
It is actually possible to serve multiple virtual hosts from the same IP (http://en.wikipedia.org/wiki/Server_Name_Indication#The_fix http://en.wikipedia.org/wiki/Server_Name_Indication#The_fix). The first technique is called Sever Name Indication, which is a way to specify a virtual host with TLS (https) negotiations by sending the virtual domain as part of the TLS negotiation The second method is a specification that introduces the subjectAltName field which allows one cert to be used across multiple subdomains (for things like wildcarding). This would make it really easy to do organization-based subdomains with TLS encryption. There are limits to which browsers and which servers can do it. It requires IE7 and up (not on XP though), and basically all recent versions of other browsers. Edit: noted that IE on XP doesn't work.
- duskwuff 16y ago
  SNI doesn't work in IE7 (or IE8) if you're running Windows XP. This ends up leaving a sizable chunk of users unable to use it.

listrophy 16y ago

From the article, it's not so much the TLS protocol that allows SSL on virtual hosts, it's specifically the Server Name Indication (SNI) TLS extension. And every major browser version supports SNI except IE6 (arguably not major anymore) and any IE on XP (except maybe IE9?).

jedsmith 16y ago
IE9 will never run on XP, so you're right, just not in a way you expect.
- listrophy 16y ago
  I thought that might be the case, but I figured I had already hit my limit on parenthetical phrases, so I didn't bother investigating.

tghw 16y ago

The real problem, according to Lafon, is that with HTTPS you lose the ability to cache. I'm fairly certain this is false, unless they're talking about proxy caching. Normal browser caching works equally well in HTTPS as it does in HTTP.

jedsmith 16y ago
The leading browsers were fairly stubborn on caching SSL resources for a while -- specifically to disk -- but (I think) most of them now obey the magic words: Cache-control: public Some data here: http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https http://stackoverflow.com/questions/174348/will-web-browsers-... I'm interested in what the state of this is, myself, but I know that one of IE 9's improvements was HTTPS conditional requests.
justinludwig 16y ago
> unless they're talking about proxy caching I'm fairly certain that's what he's talking about. A) He's Yves Lafon, and B) when you're talking web architecture, you care very much about what intermediaries can do.

kinofcain 16y ago

What I find as slightly amusing is that the major web browsers will throw up all sorts of fancy, scary warning messages if you're hitting a site with an expired or invalid certificate, but they don't say a darn thing when you hit a site over http. I understand that lying about your encryption is potentially a bigger deal than not having any at all, but still.

eapen 16y ago

Disappointed to see that this author doesn't really understand the issue he is writing about. The Firesheep tool would actually pick the cookies sent over HTTP rather than the username/password which was sent securely (in most cases). Also, as others have mentioned, it is possible to have an SSL cert installed on Virtual hosts. Dreamhost offers an option for as little as around $3-4 a month to have an SSL cert for a site. Sometimes, I wish I could downvote an article on HN.

nate 16y ago

I was doing some load testing on a new project of ours and noticed that I couldn't break 50-60 reqs per second sending all the requests through stunnel-haproxy or apache-haproxy to a cluster of app servers that should have handled about 200ish reqs per second. This wasn't a problem if the traffic wasn't encrypted. Didn't seem like a CPU bottleneck with the machine doing the load test measurements either. So I did some digging. And noticed that https://encrypted.google.com https://encrypted.google.com uses RC4_128 as a cipher. You know what Bank of America uses too? RC4_128. RC4 happens to be a much faster cipher. RC4 has gotten some bad press as it was used in WEP encryption and was cracked. But I believe it was because their RC4 implementation had a flaw rather than RC4 at 128 bis being a terrible choice for encryption? I'm not positive and would love to hear your input. I switched our load balancer to make sure we were using RC4_128 instead of AES_256, and bam I had 3-4 times more throughput of encrypted requests going through just fine.

mukyu 16y ago
The attacks used against RC4 as used in WEP are not applicable to RC4 as used in TLS connections. If you do not use related keys and discard at least the first 256 bytes, RC4 is fine. It is not that they implemented RC4 incorrectly, but that they did not account for its known weaknesses.

yason 16y ago

I'm strongly in favor of encrypting the channel even without signed certificates. A self-signing certificate doesn't authenticate the session but it can be used to later verify that the other end hasn't changed. It's much like bumping onto someone at the gym frequently but not really knowing their name or who they are. You can still trust that he's the same guy, sans having had a facial plastic surgery. Sending passwords over plaintext http is just stupid. To mount a man-in-the-middle attack you actually have to do something and position yourself between the two ends, not just listen to the passing network traffic. So, you might log on to Twitter at home (a relatively safe connection) and receive their public key and then use that to communicate with Twitter again later in public wifis or among middlemen at the airport. The browser would refuse to connect if the key doesn't match, much like ssh will complain if the host key fingerprint has changed (and require you to do manual purging of your known_hosts file). Gmail is the only one where you can tap "Always use https" on. To Facebook you can connect with https://facebook.com https://facebook.com but I don't know whether any auxiliary or Ajax/XMLRPC connections will use that.

chrisbolt 16y ago
I'm strongly in favor of encrypting the channel even without signed certificates. A self-signing certificate doesn't authenticate the session but it can be used to later verify that the other end hasn't changed. Because it's comforting to know that you handed over your private information to a man-in-the-middle and nobody else.
- pyre 16y ago
  Errr... Are we advocating HTTPS everywhere? Or just when it's time to transfer private information? When I want to read an essay on some random website, to I need to now that the website owner is who they say that they are? Isn't self-signed HTTPS better than just plain old HTTP? Or is it better that we only use HTTPS for a select few sites that aren't self-signed and HTTP everywhere else?
  - chrisbolt 16y ago
    If you're not transferring private information, why does it matter if it's encrypted? Either you care if someone can eavesdrop or you don't.

known 16y ago

HTTPS - HTTP = 3 Seconds

fierarul 16y ago

'The web' isn't using HTTPS since SSL is a nice yearly 'tax' on the domain owner. It seems to me we have a nice centralized monopoly here with the existing Certificate Authorities (most US-centric) for something as decentralized as the internet. Why can't the domain name registrar give me a SSL cert for free? I mean, if I did buy a domain name, and I'm able to change the records, it's pretty clear I own the thing. Certificate info should just be a DNS record imho. Regarding identity checks, there are other stupidities I see here: for example, my company has to send monthly/yearly papers to the government entities (some of which get publishes into some official government papers). Why can't I publish my public key there? I mean, if anything, it's very bureaucratic to do anything involving public institutions so each paper is stamped, checked, etc. I would trust more a local clerk to check for identity then some US guy that has never in his life actually seen a deed of incorporation for a Romanian entity. So, yeah, I would love to have my site with HTTPS and to sign all my JARs and emails but until this becomes more sane or my customers actually start demanding it, I'm not going to waste money on that.

bsdbuddy 16y ago
Although I absolutely agree with your whole comment, I would just like to add one point. If you doing online business, and successfully, the yearly charge shouldn't be such an issue. However, for non-profit websites its absolutely out of the question. I'm curious - as your customers aren't demanding SSL what industry are you in?
- fierarul 16y ago
  Well, the yearly charge isn't such an issue, but I cringe knowing I could pay a small server for an year of uptime with the money I pay for an SSL cert, which is essentially an official stamp of a member of the CA oligarchy. I mostly do contract work so I don't need SSL on my front-facing sites. We do use sites that have SSL to send deliverables and such, but I just pay for their service, not for the cert itself. Internally we've also used self-signed certs, our own CA or just SSH port forwarding. As an industry we should move towards encription but away from the current CA model. Somehow everybody portrays it as if it's the same thing.

kogir 16y ago

Why can't I add my site's certificate as a DNS record, use DNSSEC and be done? I don't want to give Symantec (owner of Verisign) money or trust to do something I can easily do myself.

dchest 16y ago
That's what djb's CurveCP is trying to do (http://curvecp.org/ http://curvecp.org/) (except with DNSCurve and custom protocols)
asharp 16y ago
because DNSSEC isn't required. As an example, if i mitm your dhcp request, i insert myself in as your dns server and gateway and i just say that DNSSEC isn't enabled for this domain. You have to trust me, and I can give you a MITM'd page. Similarly dnssec uses a very similar model. You need somebody to sign that your record is valid which is roughly the same as somebody signing your certificate as valid. They are both a chain of trust, they just differ slightly in implementation. I do agree with you that using dnssec makes more sense then our current system.

jeza 16y ago

Living in Australia, I can tell you the main reason caching is so important is because our main telco decided to charge by megabytes of usage. Back in the days when most of us were stuck on dialup, they were charging $0.18 a megabyte. At least the slow speeds limited the damage, though downloading a 600MB would still have cost a ridiculous $108. Meanwhile the rest of the world hadn't even though of charing such tariffs for internet usage. Of course once you have one company setting the standard then their competitors all follow suite. While things have improved tremendously since then, broadband plans are still based around download and sometimes even upload usage. At least now you're looking at something more reasonable like $50/month for 50 gigabytes a month of included download usage. So originally caching would actually save you serious money (unfortunately ISPs rarely passed on these savings to customers if they used their proxy server). Though nowadays it's less important as long as the websites you visit are responsive. Granted you're always going to have some kind of client side cache.

PHPAdam 16y ago

Its due to SSL Tax should be included free with every IP. IMHO.