11 ms·

How about we solve the "certificate" situation first? I've just paid lots of money for "certificates". I quote the word, because they don't actually certify or

by jwr 12y ago

How about we solve the "certificate" situation first? I've just paid lots of money for "certificates". I quote the word, because they don't actually certify or even signify anything. The whole procedure for "domain-verification" is a joke, and many outfits are incompetently run (their "verification" e-mails bounced from my servers because they ended up in RBL, which nobody seemed fit to correct). I see this as a scam, or extortion — pay up, or you won't be "certified". And pay up significant amounts of money, if you want a wildcard cert. If we care about encryption just for the sake of encryption, let's change our browsers to allow self-signed certificates. Label them as such, but don't label them as "unsecure", because the padlock icon really isn't any more secure than a self-signed cert.

glesica 12y ago
This is especially bad on Firefox where the dialog to allow a self-signed cert isn't even very intuitive. At least on Chrome (last I checked, anyway) there is a clear "correct" thing to do if you want to allow the cert.
byuu 12y ago
But what kind of technology would think self-signed certificates could ever be better (let alone not infinitely worse) than no encryption at all? That sounds like hell. We should call this new, purely hypothetical protocol, SSHell, or SSH for short. Not that such a thing would ever be used by anyone, of course. (Yes, I know that technically SSH uses key pairs; but they show you the key, you choose to trust it. Same real chance of a MITM as with a self-signed SSL certificate. But at least you (and others) can now detect when there's a change in who's sending your data, and choose who to trust yourself instead of relying on Mozilla to pick who to trust, like they did CNNIC.)
- rando3826 12y ago
  Lol, took me a minute to get the sarcasm.
- xorcist 12y ago
  The trust-on-first-use model makes it hard or impossible to regenerate certificates. If you don't have that problem with SSH it is because you connect to your own servers only. There have been several attempts for a distributing certificate checks on the wider Internet, but they all come with their own set of problems.
  - mikeash 12y ago
    Alternately, you do have that problem with SSH, and you work around it by scratching your head, saying "oh, right, because I switched hosts/reinstalled the OS/ran that mysterious command," and then nuking the key entry. Alas, this does not scale well into the HTTP realm.
    - ay 12y ago
      What about trusting not the key itself, but the CA which signed the cert - whose cert came within the cert chain upplied by the server ? Then everyone could get their own "root" CA and renew the certificates to their heart's content.
- profmonocle 12y ago
  The problem is it requires knowledgable, involved users if the private key ever needs to change. If I suddenly get an SSH key error on a company server, I can just ask the sysadmin if it's legit. That wouldn't really work on sites intended for the general public - users would just click "ok" on every error or they'd be scared off. Although I think it could work great on sites intended for small numbers of clueful users. (Web-based admin consoles, etc.) But something else is needed to make HTTPS usable by average people.
  - byuu 12y ago
    Oh, certainly. I agree completely with everything you said. But right now, the situation is that I go to arstechnica.com, which offers no encryption whatsoever, and Firefox just loads it up like nothing's wrong. Yet I go to self-signed.example.com, and Firefox presents me with a giant warning screen, followed by a pop-open warning dialog, where I have to click to confirm the security exemption, add the certificate in, and OK another scary prompt. It's so over the top that laymen probably think proceeding will give that site complete interception control over every site they ever go to again in the future. That's absolutely ridiculous. Worst case, self-signed should be treated like HTTP is now. No padlock, no green address bar. People who are knowledgeable and able to confirm self-signed certs should be able to very quickly and very easily do so. This will greatly help with developing inside the local network, or for small communities that know what they're doing and don't want to pay hundreds of dollars for wildcard SSL certs.
    - bandrami 12y ago
      This. A self-signed certificate is significantly better than no encryption whatsoever (even if you're being phished, you at least now know that no other phisher has viewed or altered the response in transit), but browsers for reasons that defy explanation treat them like they're worse. There was even an MTA (exim maybe?) that on seeing an untrusted certificate would actually downgrade to plaintext in some circumstances. Great job, guys; you really dodged a bullet there...
kej 12y ago
How do you check the difference between your self-signed cert for your site and my self-signed cert for your site?
- higherpurpose 12y ago
  This might help: http://www.coniks.org/ http://www.coniks.org/
- MatthewWilkes 12y ago
  Considering that's something we can't do at the moment with http I hardly think it's important. If nothing else, using https means purely passive attacks aren't possible. Active attacks are much easier for devices to spot by looking for key changes, too.
  - IgorPartola 12y ago
    But would you use gmail.com over plain HTTP? Would you use it if it presented a self-signed cert?
    - bandrami 12y ago
      You know gmail.com is one of the domains with known invalid certs signed by browser-supported CAs in the wild, right?
    - MatthewWilkes 12y ago
      No, but check out how XKCD is presented at the moment. It doesn't look like it's secure or insecure, it looks like http. I would happily read webcomics over a self-signed certificate if it was made easy for me. We don't need identity verification on many sites, being resistant to passive eavesdroppers or transient active attackers (such as sites that present different SSL certs when accessed from a public wifi) is a nice to have as they prevent some attacks rather than none.
      - IgorPartola 12y ago
hannob 12y ago
You can get normal certificates for free these days and wildcard certs don't cost significant amounts of money. At startssl you can get unlimited amounts of wildcard certs for 60 $. I know startssl isn't that popular and partly that's justified. In summer hopefully let's encrypt will start and make it even easier to get certs for free. Or in other words: People are working on solving the certificate situation - and even now it is not as bad as you make it sound.
- StephanieH 12y ago
  To get free ssl certificate from reputed SSL CA like startssl, rapidssl, geotrust, thawte, comodo is the best decision. If talking about wildcard ssl certificate then startssl price is very high because I found $40 price for wildcard ssl certificate at resource http://www.cheapsslcouponcode.com/coupons/wildcard-ssl-certificates http://www.cheapsslcouponcode.com/coupons/wildcard-ssl-certi...
skywhopper 12y ago
Agreed. Enforcing SSL on the entire web will just mean a lot of very sloppy and bad SSL. Better to just make it abundantly clear when traffic is insecure, because that's a problem you'll have to solve whether you force SSL or not.
baby 12y ago
> the padlock icon really isn't any more secure than a self-signed cert. I understand this comes from a frustration, and an understanding that the certificate based authentication is not perfect. But labeling it as "as secure as a self-signed cert" when a self-signed certificate provide no authentication (or an unpractical one at best) is uncalled for. So as long as no practical and better solution for server authentication has been found, this is the best we have and it is still working pretty well (you don't see a lot of rogue certificates in the wild).
- yellowapple 12y ago
  > But labeling it as "as secure as a self-signed cert" when a self-signed certificate provide no authentication (or an unpractical one at best) is uncalled for. It's perfectly called for. The CA system is based on arbitrary trust. An actually-effective system should not rely on trust at all. Even something like what Namecoin does - using a Bitcoin-style blockchain as a public ledger, but for SSL certs instead of DNS entries - would be a massive step in the right direction in comparison to the current CA system.
  - srj 12y ago
    It's not entirely arbitrary. Some CAs may actually be worthy of trust. I imagine it would be possible to modify the browser's UI to reflect the trustworthiness of the server certificate to encourage better diligence on their part.
    - Corporate_Shill 12y ago
      ""not entirely arbitrary.""
    - yellowapple 12y ago
      > Some CAs may actually be worthy of trust. By what measure? Some empty promises of good security practices, perhaps? Or maybe some pinky swear that they'll always act in the best interests of the internet as a whole rather than in the interests of whichever government or set of shareholders happens to be in a position of power relative to them? Basically: name one.
omphalos 12y ago
I wonder if web-of-trust SSL is the right way to solve this.
- yellowapple 12y ago
  On its own, probably not; web-of-trust is one of those things about PGP that was awesome on paper, but in practice ended up being a significant pain point. A cryptographic ledger, on the other hand (think Namecoin), would probably be at least slightly more effective; it would effectively confer the same benefits (decentralized registration authority) without the logistical nightmare of a web-of-trust.
copsarebastards 12y ago
How about we solve both these problems and stop quibbling about which one we should solve first, given that they both need to be solved?
- byuu 12y ago
  I'd rather not spend hundreds on a wildcard cert, or thousands on an EV cert, plus the costs in setting it up, until I'm sure the model is actually sound. Trusting CNNIC, no DNSSEC, etc show that Mozilla and Google aren't taking this very seriously. It's more a dog and pony show at this point with encryption. Plus I'm still cognizant of the bullet I dodged by not having OpenSSL on my server back when Heartbleed hit.
  - copsarebastards 12y ago
    > I'd rather not spend hundreds on a wildcard cert, or thousands on an EV cert, plus the costs in setting it up, until I'm sure the model is actually sound. I'm 100% sure the model isn't sound. I'm also 100% sure that a model which includes unencrypted HTTP will never be sound. The cert problem is a fixable problem, but it's not fixable while unencrypted HTTP exists.
    - yellowapple 12y ago
      > The cert problem is a fixable problem, but it's not fixable while unencrypted HTTP exists. Sure it is. Whether or not HTTP exists has zero bearing on solutions to the cert problem; the cert problem is independent of the unencrypted problem (whereas the unencrypted problem is dependent on the cert problem, since the cert problem is precisely why the unencrypted problem currently exists).
    - stephengillie 12y ago
      Chicken, meet egg.
      - copsarebastards 12y ago
_yosefk 12y ago
It seems kinda wrong to require encryption for say a static website receiving no input from the user in the first place. Perhaps the web browser's shouting about security issues could be delayed until the moment when something happens where security is relevant.
- hannob 12y ago
  Even on a static page you want to be sure that what you see is what the server sent. Without any third party injecting anything. That's what comments like this like to forget: HTTPS provides not only encryption, but also authenticatoin.
  - bandrami 12y ago
    > Even on a static page you want to be sure that what you see is what the server sent. So have a PGP signature of the page available and the browser can check it. > HTTPS provides not only encryption, but also authenticatoin. And this is the problem. Those are two separate issues and should be handled separately.
    - deleted 12y ago
      [deleted]
  - CamperBob2 12y ago
    Yessiree, Bob, those are my cat pictures, and here's the 1024-bit key to prove it.
  - Animats 12y ago
    That's what subresource integrity[1] is for. Links will have a secure hash of the content they link to. So you don't have to secure page assets such as pictures, CSS, Javascript, fonts, etc - just the entry pages for a site. This cuts the need for encrypted traffic way down. This has a big advantage over HTTPS Everywhere - neither you nor your users have to trust your CDN. Put your main pages' HTML, and special pages such as login and transaction pages, on your own HTTPS server, and the public stuff on some CDN, unencrypted. This is much more secure than letting some CDN possess your private keys. [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
STRML 12y ago
If all a domain-validation SSL cert means is that the certificate issuer could reach you via admin/administrator@domain.com - that's nearly all they do, besides ask for some payment information - why not automate that part of the process? That is, the certificate presented by the site should be signed in a fashion that proves that whoever signed it owns the domain. How do we know you own the domain? Because you control the DNS. If you control the DNS, you can control the domain in so many ways, including receiving the DV email, so it seems like a proper way to verify it. If you control DNS, you can set a TXT record and put a public key in it. So why not have browsers actually just ensure that a certificate is signed by the public key stored in DNS? Is there a good reason not to do this?
- mikeash 12y ago
  Might just be because you need DNSSec for that technique to be viable (otherwise an attacker could just spoof the DNS response too) and that hasn't been widely available until recently. Offhand it sounds like a pretty good approach now.
  - IgorPartola 12y ago
    Point is, this is what we do now. We do this without DNSSEC. The step of receiving the email is pretty much redundant and is only there because people understand email better than creating a TXT record. DNSSEC is a terrible ide and should be abandoned for many reasons. So should this method of domain validation. You know who knows for sure that you own the domain you say you own? The registrar. That is who should issue you your cert, not some third party.
- clinta 12y ago
  This is called DANE described in RFC 6698. But it requires DNSSEC. Without DNSSEC, the visitor to the site can be easily be MITM'd by spoofing DNS. It is presumably more secure when a CA verifies an email (or DNS) because the CA can control their DNS servers and be reasonably sure their DNS is not spoofed. Random clients internet clients can't without DNSSEC.
gwu78 12y ago
Well-stated. You are not the only one.
dlitz 12y ago
Let's Encrypt is scheduled to launch in mid-2015, so by later this year, the procedure to get a proper certificate will be something like: sudo apt-get install lets-encrypt lets-encrypt example.com https://letsencrypt.org/howitworks/ https://letsencrypt.org/howitworks/
mark_l_watson 12y ago
You make a good point. This might be more of a UI issue: perhaps self-signed certificates could use a different browser icon that lets people know traffic is encrypted, but the identity of the site is not verified. Use a large "E" in the icon? I don't mind at all visiting someone's personal site that has a self signed certificate but a UI change to avoid the glaring waring dialog would be nice. There are large advantages of having almost all traffic encrypted.

by jwr 12y ago

glesica 12y ago

This is especially bad on Firefox where the dialog to allow a self-signed cert isn't even very intuitive. At least on Chrome (last I checked, anyway) there is a clear "correct" thing to do if you want to allow the cert.

byuu 12y ago

But what kind of technology would think self-signed certificates could ever be better (let alone not infinitely worse) than no encryption at all? That sounds like hell. We should call this new, purely hypothetical protocol, SSHell, or SSH for short. Not that such a thing would ever be used by anyone, of course. (Yes, I know that technically SSH uses key pairs; but they show you the key, you choose to trust it. Same real chance of a MITM as with a self-signed SSL certificate. But at least you (and others) can now detect when there's a change in who's sending your data, and choose who to trust yourself instead of relying on Mozilla to pick who to trust, like they did CNNIC.)

rando3826 12y ago
Lol, took me a minute to get the sarcasm.
xorcist 12y ago
The trust-on-first-use model makes it hard or impossible to regenerate certificates. If you don't have that problem with SSH it is because you connect to your own servers only. There have been several attempts for a distributing certificate checks on the wider Internet, but they all come with their own set of problems.
- mikeash 12y ago
  Alternately, you do have that problem with SSH, and you work around it by scratching your head, saying "oh, right, because I switched hosts/reinstalled the OS/ran that mysterious command," and then nuking the key entry. Alas, this does not scale well into the HTTP realm.
  - ay 12y ago
    What about trusting not the key itself, but the CA which signed the cert - whose cert came within the cert chain upplied by the server ? Then everyone could get their own "root" CA and renew the certificates to their heart's content.
profmonocle 12y ago
The problem is it requires knowledgable, involved users if the private key ever needs to change. If I suddenly get an SSH key error on a company server, I can just ask the sysadmin if it's legit. That wouldn't really work on sites intended for the general public - users would just click "ok" on every error or they'd be scared off. Although I think it could work great on sites intended for small numbers of clueful users. (Web-based admin consoles, etc.) But something else is needed to make HTTPS usable by average people.
- byuu 12y ago
  Oh, certainly. I agree completely with everything you said. But right now, the situation is that I go to arstechnica.com, which offers no encryption whatsoever, and Firefox just loads it up like nothing's wrong. Yet I go to self-signed.example.com, and Firefox presents me with a giant warning screen, followed by a pop-open warning dialog, where I have to click to confirm the security exemption, add the certificate in, and OK another scary prompt. It's so over the top that laymen probably think proceeding will give that site complete interception control over every site they ever go to again in the future. That's absolutely ridiculous. Worst case, self-signed should be treated like HTTP is now. No padlock, no green address bar. People who are knowledgeable and able to confirm self-signed certs should be able to very quickly and very easily do so. This will greatly help with developing inside the local network, or for small communities that know what they're doing and don't want to pay hundreds of dollars for wildcard SSL certs.
  - bandrami 12y ago
    This. A self-signed certificate is significantly better than no encryption whatsoever (even if you're being phished, you at least now know that no other phisher has viewed or altered the response in transit), but browsers for reasons that defy explanation treat them like they're worse. There was even an MTA (exim maybe?) that on seeing an untrusted certificate would actually downgrade to plaintext in some circumstances. Great job, guys; you really dodged a bullet there...

kej 12y ago

How do you check the difference between your self-signed cert for your site and my self-signed cert for your site?

higherpurpose 12y ago
This might help: http://www.coniks.org/ http://www.coniks.org/
MatthewWilkes 12y ago
Considering that's something we can't do at the moment with http I hardly think it's important. If nothing else, using https means purely passive attacks aren't possible. Active attacks are much easier for devices to spot by looking for key changes, too.
- IgorPartola 12y ago
  But would you use gmail.com over plain HTTP? Would you use it if it presented a self-signed cert?
  - bandrami 12y ago
    You know gmail.com is one of the domains with known invalid certs signed by browser-supported CAs in the wild, right?
  - MatthewWilkes 12y ago
    No, but check out how XKCD is presented at the moment. It doesn't look like it's secure or insecure, it looks like http. I would happily read webcomics over a self-signed certificate if it was made easy for me. We don't need identity verification on many sites, being resistant to passive eavesdroppers or transient active attackers (such as sites that present different SSL certs when accessed from a public wifi) is a nice to have as they prevent some attacks rather than none.
    - IgorPartola 12y ago

hannob 12y ago

You can get normal certificates for free these days and wildcard certs don't cost significant amounts of money. At startssl you can get unlimited amounts of wildcard certs for 60 $. I know startssl isn't that popular and partly that's justified. In summer hopefully let's encrypt will start and make it even easier to get certs for free. Or in other words: People are working on solving the certificate situation - and even now it is not as bad as you make it sound.

StephanieH 12y ago
To get free ssl certificate from reputed SSL CA like startssl, rapidssl, geotrust, thawte, comodo is the best decision. If talking about wildcard ssl certificate then startssl price is very high because I found $40 price for wildcard ssl certificate at resource http://www.cheapsslcouponcode.com/coupons/wildcard-ssl-certificates http://www.cheapsslcouponcode.com/coupons/wildcard-ssl-certi...

skywhopper 12y ago

Agreed. Enforcing SSL on the entire web will just mean a lot of very sloppy and bad SSL. Better to just make it abundantly clear when traffic is insecure, because that's a problem you'll have to solve whether you force SSL or not.

baby 12y ago

> the padlock icon really isn't any more secure than a self-signed cert. I understand this comes from a frustration, and an understanding that the certificate based authentication is not perfect. But labeling it as "as secure as a self-signed cert" when a self-signed certificate provide no authentication (or an unpractical one at best) is uncalled for. So as long as no practical and better solution for server authentication has been found, this is the best we have and it is still working pretty well (you don't see a lot of rogue certificates in the wild).

yellowapple 12y ago
> But labeling it as "as secure as a self-signed cert" when a self-signed certificate provide no authentication (or an unpractical one at best) is uncalled for. It's perfectly called for. The CA system is based on arbitrary trust. An actually-effective system should not rely on trust at all. Even something like what Namecoin does - using a Bitcoin-style blockchain as a public ledger, but for SSL certs instead of DNS entries - would be a massive step in the right direction in comparison to the current CA system.
- srj 12y ago
  It's not entirely arbitrary. Some CAs may actually be worthy of trust. I imagine it would be possible to modify the browser's UI to reflect the trustworthiness of the server certificate to encourage better diligence on their part.
  - Corporate_Shill 12y ago
    ""not entirely arbitrary.""
  - yellowapple 12y ago
    > Some CAs may actually be worthy of trust. By what measure? Some empty promises of good security practices, perhaps? Or maybe some pinky swear that they'll always act in the best interests of the internet as a whole rather than in the interests of whichever government or set of shareholders happens to be in a position of power relative to them? Basically: name one.

omphalos 12y ago

I wonder if web-of-trust SSL is the right way to solve this.

yellowapple 12y ago
On its own, probably not; web-of-trust is one of those things about PGP that was awesome on paper, but in practice ended up being a significant pain point. A cryptographic ledger, on the other hand (think Namecoin), would probably be at least slightly more effective; it would effectively confer the same benefits (decentralized registration authority) without the logistical nightmare of a web-of-trust.

copsarebastards 12y ago

How about we solve both these problems and stop quibbling about which one we should solve first, given that they both need to be solved?

byuu 12y ago
I'd rather not spend hundreds on a wildcard cert, or thousands on an EV cert, plus the costs in setting it up, until I'm sure the model is actually sound. Trusting CNNIC, no DNSSEC, etc show that Mozilla and Google aren't taking this very seriously. It's more a dog and pony show at this point with encryption. Plus I'm still cognizant of the bullet I dodged by not having OpenSSL on my server back when Heartbleed hit.
- copsarebastards 12y ago
  > I'd rather not spend hundreds on a wildcard cert, or thousands on an EV cert, plus the costs in setting it up, until I'm sure the model is actually sound. I'm 100% sure the model isn't sound. I'm also 100% sure that a model which includes unencrypted HTTP will never be sound. The cert problem is a fixable problem, but it's not fixable while unencrypted HTTP exists.
  - yellowapple 12y ago
    > The cert problem is a fixable problem, but it's not fixable while unencrypted HTTP exists. Sure it is. Whether or not HTTP exists has zero bearing on solutions to the cert problem; the cert problem is independent of the unencrypted problem (whereas the unencrypted problem is dependent on the cert problem, since the cert problem is precisely why the unencrypted problem currently exists).
  - stephengillie 12y ago
    Chicken, meet egg.
    - copsarebastards 12y ago

_yosefk 12y ago

It seems kinda wrong to require encryption for say a static website receiving no input from the user in the first place. Perhaps the web browser's shouting about security issues could be delayed until the moment when something happens where security is relevant.

hannob 12y ago
Even on a static page you want to be sure that what you see is what the server sent. Without any third party injecting anything. That's what comments like this like to forget: HTTPS provides not only encryption, but also authenticatoin.
- bandrami 12y ago
  > Even on a static page you want to be sure that what you see is what the server sent. So have a PGP signature of the page available and the browser can check it. > HTTPS provides not only encryption, but also authenticatoin. And this is the problem. Those are two separate issues and should be handled separately.
  - deleted 12y ago
    [deleted]
- CamperBob2 12y ago
  Yessiree, Bob, those are my cat pictures, and here's the 1024-bit key to prove it.
- Animats 12y ago
  That's what subresource integrity[1] is for. Links will have a secure hash of the content they link to. So you don't have to secure page assets such as pictures, CSS, Javascript, fonts, etc - just the entry pages for a site. This cuts the need for encrypted traffic way down. This has a big advantage over HTTPS Everywhere - neither you nor your users have to trust your CDN. Put your main pages' HTML, and special pages such as login and transaction pages, on your own HTTPS server, and the public stuff on some CDN, unencrypted. This is much more secure than letting some CDN possess your private keys. [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/

STRML 12y ago

If all a domain-validation SSL cert means is that the certificate issuer could reach you via admin/administrator@domain.com - that's nearly all they do, besides ask for some payment information - why not automate that part of the process? That is, the certificate presented by the site should be signed in a fashion that proves that whoever signed it owns the domain. How do we know you own the domain? Because you control the DNS. If you control the DNS, you can control the domain in so many ways, including receiving the DV email, so it seems like a proper way to verify it. If you control DNS, you can set a TXT record and put a public key in it. So why not have browsers actually just ensure that a certificate is signed by the public key stored in DNS? Is there a good reason not to do this?

mikeash 12y ago
Might just be because you need DNSSec for that technique to be viable (otherwise an attacker could just spoof the DNS response too) and that hasn't been widely available until recently. Offhand it sounds like a pretty good approach now.
- IgorPartola 12y ago
  Point is, this is what we do now. We do this without DNSSEC. The step of receiving the email is pretty much redundant and is only there because people understand email better than creating a TXT record. DNSSEC is a terrible ide and should be abandoned for many reasons. So should this method of domain validation. You know who knows for sure that you own the domain you say you own? The registrar. That is who should issue you your cert, not some third party.
clinta 12y ago
This is called DANE described in RFC 6698. But it requires DNSSEC. Without DNSSEC, the visitor to the site can be easily be MITM'd by spoofing DNS. It is presumably more secure when a CA verifies an email (or DNS) because the CA can control their DNS servers and be reasonably sure their DNS is not spoofed. Random clients internet clients can't without DNSSEC.

gwu78 12y ago

Well-stated. You are not the only one.

dlitz 12y ago

Let's Encrypt is scheduled to launch in mid-2015, so by later this year, the procedure to get a proper certificate will be something like: sudo apt-get install lets-encrypt lets-encrypt example.com https://letsencrypt.org/howitworks/ https://letsencrypt.org/howitworks/

mark_l_watson 12y ago

You make a good point. This might be more of a UI issue: perhaps self-signed certificates could use a different browser icon that lets people know traffic is encrypted, but the identity of the site is not verified. Use a large "E" in the icon? I don't mind at all visiting someone's personal site that has a self signed certificate but a UI change to avoid the glaring waring dialog would be nice. There are large advantages of having almost all traffic encrypted.