5 ms·

Most arguments I've seen against HTTPS everywhere seem to fail to realise that it's not just the data confidentiality that's important, it's the integrity too.

by growse 12y ago

Most arguments I've seen against HTTPS everywhere seem to fail to realise that it's not just the data confidentiality that's important, it's the integrity too. If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place? If you do care about it being wrong, HTTPS isn't a bad way to help ensure that what you're getting is what the server is giving out. It's not perfect, but nothing is.

josteink 12y ago
> If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place? If that's the argument, it reasonably applies to everything, everywhere, and we should scrap TCP alltogether. Instead we need to implement a replacement which ensures everything everywhere at every level of every stack does crypto as well. Let's call it STCP! Or does that suddenly sounds zealous? It just follows from your base argument.
- personjerry 12y ago
  This counter-argument fails because HTTPS is much easier to implement and web servers already use it. Whereas TCP is much lower level and to make "STCP" we would have to recode servers entirely to handle both TCP and STCP requests from clients.
- molf 12y ago
  Or Google calls it QUIC [1]. And it's exactly that, a replacement for TCP with TLS. [1] http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
- lmm 12y ago
  Cryptography cannot be separated from authentication, and only the application can know how to do authentication. E.g. emails are designed to be forwarded between servers and not care about the exact path they take, so it would be foolish to apply hostname-based encryption to emails; instead emails are (or should be) encrypted using S/MIME or OpenPGP, to the specific intended recipient. It's then fine, indeed desirable, for these encrypted emails to be passed around over cleartext transports such as TCP.
  - bandrami 12y ago
    > Cryptography cannot be separated from authentication Frequently repeated but still wrong. Cryptography requires one of the following: 1. Two key pairs, or 2. A shared secret. The shared secret implies authenticity. But there are entire classes of cryptosystems based on not knowing with whom you are communicating. Crypto establishes a channel through which Alice and Bob can then negotiate authenticity. (To put it in simple terms: it's better to be phished over secure transport than to be phished over plaintext.) For some reason, a large number of people seem to have completely skipped over this basic advantage of unauthenticated channels: you have now isolated the communication to you and your prospective phisher. This is a gain, this is an advantage, and it borders on absurd that people go to such lengths to deny this.
    - frankzinger 12y ago
      >> Cryptography cannot be separated from authentication > Frequently repeated but still wrong. > The shared secret implies authenticity. Just checking: are you aware of the concept of authenticated encryption (https://en.wikipedia.org/wiki/Authenticated_encryption https://en.wikipedia.org/wiki/Authenticated_encryption) and its importance?
  - dtech 12y ago
    Cryptography without authentication still provides protection against (non-MITM) eavesdroppers, which is very important with public wifi networks nowadays. Which is why it's strange that self-signed connections are represented to the user as dangerous, while unencrypted connections do not have such a warning even though the former is strictly better.
    - ryanlol 12y ago
      Scenarios where the attacker is restricted to being a non-MITM eavesdropper are pretty rare, public wifi networks aren't an example of such.
      - tveita 12y ago
- growse 12y ago
  TCP is a transport level protocol. It's job is to get messages from A to B in a way that tries to guarantee delivery (amongst other properties). HTTP is an application level protocol, it's job is to encapsulate messages and commands between two applications that may be remote. We have already built mechanisms that secure traffic on the transport layer (see IPSec) and they actually work well when they're needed/useful. It turns out that right now, securing data on the application layer is much easier / cheaper than trying to do IPSec everywhere. Finally, HTTP is a bit of a special case, because much of the time data delivered over HTTP is code that's going to be executed on a client's machine. If anything, this makes it much more important that the integrity is preserved.
  - deleted 12y ago
    [deleted]
- deleted 12y ago
  [deleted]
- kpcyrd 12y ago
  There's actually a crypto IP replacement out there: https://github.com/hyperboria/cjdns https://github.com/hyperboria/cjdns
  - __david__ 12y ago
    Also djb's http://curvecp.org http://curvecp.org
- wtbob 12y ago
  Why would that sound zealous? It really would be nice if crypto were part of the foundations of the Internet, rather than applied as window-dressing. It'd require some hard thought about what guarantees are possible and desirable, but that'd be a good thing.
treffer 12y ago
HTTP: here is the length (response header) and here is the payload transfered with checksums (tcp). HTTP has quite good integrity of the data you requested. If you mean HTTPs is great to check if it's coming from the right server (identity/authority) then well, see how well the CA system works and how weak certificates really are (e.g. "Ron was wrong, Whit is right"). You can work around that by doing certificate pinning (see google chrome for example) and stuff like that, but in that case I'd already be better off signing the payload and sending that as part of the response. The scientific institutes of germany worked around all the CA headaches by becoming an intermediate CA (see who signed https://www.pki.dfn.de/ https://www.pki.dfn.de/ ). I'd just expect more intermediate CAs popping up as a result of HTTPs only which will weaken HTTPs even more. (And yes, I'm using https everywhere and would enable https for just about every site, except e.g. for linux iso downloads and alike)
- wglb 12y ago
  HTTP has quite good integrity of the data you requested Not for the values of "integrity" that include the possibility of intermediate tampering. You have no indication that the request received by the server is the one you sent, nor the response that you received is the one that the server sent.
IanCal 12y ago
> If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place Perhaps I'm not overly concerned with the prospect of someone altering a gif of a cat falling over because someone put ham on its face. People can send me fake letters and post can be intercepted but it's still useful. I'm not saying that security isn't important or that we shouldn't be securing more than we are but the argument that it's vital everything is secured is clearly false. There is traffic that I simply do not care if it is public, and the risk of it being modified (and the consequences if it is) are so low that I think the added time and stress of worrying about it would be more detrimental to me.
- growse 12y ago
  So if I intercepted kittens.gif and altered the content type to be 'text/javascript' and the body to be a javascript payload that tries to exploit your browser, you're not overly concerned?
  - ryanlol 12y ago
    Not really assuming said gif is inside an img tag.
  - pdpi 12y ago
    I'd be more worried about my UA not being able to handle that scenario by just refusing to run that javascript payload.
  - lewisl9029 12y ago
    A more realistic situation could be a malicious attacker intercepting the cat picture and replacing it with an image containing something that could land the viewer in jail for having any trace of it on his computer (child pornography), and then sending an anonymous tip to law enforcement...
  - IanCal 12y ago
    Not really, since javascript loaded into an image tag shouldn't run and I was already following an unknown link to an unknown location coming from an unknown server. The risk that it was intercepted by you is low, and the consequences seem to be low too. You're also skipping straight over the risk that it happens at all, which is a fairly important part of a risk assessment.
edwintorok 12y ago
HTTP is very useful for caching and mirrors for Linux distributions because signatures are checked by package managers outside of the transport protocol.
- rlpb 12y ago
  And additionally signature verification provides far better security than HTTPS on its own because a compromised mirror cannot compromise the signature.
  - rythie 12y ago
    What about confidentiality of the package downloads though? e.g. Snoop the traffic, notice they are downloading a fix, they probably don't have it, automatically attack them before they apply it.
    - vacri 12y ago
      If you had the capability to deliver a prepared attack that quickly, you could probably already just attack them outright.
    - rlpb 12y ago
      HTTPS doesn't protect much from that either. A third party can figure out what you just downloaded based on the download size, since the size of package files are well known. Even if there is some uncertainty between sets of packages it could be inferred from your other downloads, since decisions on what to download are based on known logic (dependency tree, what the victim likely had installed before, etc). I suppose in your case the window would be smaller using HTTPS, as the package downloaded could probably be inferred only after the download is complete. But your method would need automation anyway, so I don't think the difference in timing would really matter in practice. But if you are in the position to automatically attack someone, why wait to see if they are downloading a fix? Why not just try to attack with known recent vulnerabilities anyway?
- icebraining 12y ago
pjc50 12y ago
We could really do with an HTTP referent-integrity specification. Just as you specify the size of a linked image, you could add a hash to specify the expected content of a resource. Particularly useful with large linked non-browser resouces. http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/ https://wiki.whatwg.org/wiki/Link_Hashes https://wiki.whatwg.org/wiki/Link_Hashes
ryanlol 12y ago
Except HTTPS does not (currently) solve data integrity issues in real life use cases, getting a certificate issued for someone else's domains is far from difficult... Especially since DNS is still plaintext.
- talideon 12y ago
  DNSSEC is meant to solve the integrity issue. Now, whether you feel it actually does the job is another matter. Personally, I use it on three domains, one which was done for testing purposes, and the other two because there are DNS records I would like to keep secure from manipulation. It'd be nice if TLSA/DANE was more widely supported, if only to be an additional bar against certificate forgery, but unfortunately it's not. It'd be good if DNS servers other than Knot had decent native support for signing, but they don't in general.
- icebraining 12y ago
  getting a certificate issued for someone else's domains is far from difficult Is it? Please provide a cert for ycombinator.com. Thanks.
  - ryanlol 12y ago
    http://krebsonsecurity.com/2015/02/webnic-registrar-blamed-for-hijack-of-lenovo-google-domains/ http://krebsonsecurity.com/2015/02/webnic-registrar-blamed-f... http://www.zdnet.com/article/revenge-hack-put-5-5-million-domain-names-allegedly-at-risk/ http://www.zdnet.com/article/revenge-hack-put-5-5-million-do... http://www.educause.edu/educause-security-breach-and-password-change-information http://www.educause.edu/educause-security-breach-and-passwor... If you're missing my point, these all of these hacked orgs had the capability to issue SSL certs.
    - icebraining 12y ago
      From what I can tell, they're only resellers, the companies that actually issue the certs are GeoTrust and Symantec. In any case, I know it can and does happen, I just don't agree that it is "far from difficult". Having to hack an SSL provider is out of reach for the vast majority online thieves and casual snoopers.
deskamess 12y ago
jhourcle has addressed this for his type of data with an https side channel for checksums of files available for download. See the response to the comments (also explains why rsync is not appropriate in their system for a specific class of file). jhourcle is not against https, but he/she wants the ability to use http where an exception is needed. The cost of the certificate is negligible, but the ability to keep a fragmented, heterogeneous (age wise) environment is part and parcel of the job, and NO additional funding is being provided to accomplish or operate this under https. From reading the original and the response to other comments, it is apparent to me that jhourcle has thought this through and is only asking for an exception process that they can file for. Just as they do today for systems that are not in compliance (not related to https) for various reasons (ref: comment response).
jasonkester 12y ago
Imagine you've MITM'd funnycatpictures.com. Why, as an end user would I care about the integrity of the funny cat picture you maliciously send me. Provided it is still a funny picture of a cat, your evil http version of the website is still just as useful as the original. There are a lot more funny cat picture sites than banking websites. They are fine using the same protocol they have been since 1995.
- MichaelGG 12y ago
  Deliver porn, spam, political messages, or illegal content. Or MITM a recipes site and deliver incorrect dietary advice. MITM someone's personal site and add small comments that imply they wish the KKK was a stronger political force, thus discrediting them.
  - josteink 12y ago
    Maybe someone even MITMed the comments on this page I'm reading right now, but I'm not going to be awfully worried about that.

by growse 12y ago

josteink 12y ago

> If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place? If that's the argument, it reasonably applies to everything, everywhere, and we should scrap TCP alltogether. Instead we need to implement a replacement which ensures everything everywhere at every level of every stack does crypto as well. Let's call it STCP! Or does that suddenly sounds zealous? It just follows from your base argument.

personjerry 12y ago
This counter-argument fails because HTTPS is much easier to implement and web servers already use it. Whereas TCP is much lower level and to make "STCP" we would have to recode servers entirely to handle both TCP and STCP requests from clients.
molf 12y ago
Or Google calls it QUIC [1]. And it's exactly that, a replacement for TCP with TLS. [1] http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
lmm 12y ago
Cryptography cannot be separated from authentication, and only the application can know how to do authentication. E.g. emails are designed to be forwarded between servers and not care about the exact path they take, so it would be foolish to apply hostname-based encryption to emails; instead emails are (or should be) encrypted using S/MIME or OpenPGP, to the specific intended recipient. It's then fine, indeed desirable, for these encrypted emails to be passed around over cleartext transports such as TCP.
- bandrami 12y ago
  > Cryptography cannot be separated from authentication Frequently repeated but still wrong. Cryptography requires one of the following: 1. Two key pairs, or 2. A shared secret. The shared secret implies authenticity. But there are entire classes of cryptosystems based on not knowing with whom you are communicating. Crypto establishes a channel through which Alice and Bob can then negotiate authenticity. (To put it in simple terms: it's better to be phished over secure transport than to be phished over plaintext.) For some reason, a large number of people seem to have completely skipped over this basic advantage of unauthenticated channels: you have now isolated the communication to you and your prospective phisher. This is a gain, this is an advantage, and it borders on absurd that people go to such lengths to deny this.
  - frankzinger 12y ago
    >> Cryptography cannot be separated from authentication > Frequently repeated but still wrong. > The shared secret implies authenticity. Just checking: are you aware of the concept of authenticated encryption (https://en.wikipedia.org/wiki/Authenticated_encryption https://en.wikipedia.org/wiki/Authenticated_encryption) and its importance?
- dtech 12y ago
  Cryptography without authentication still provides protection against (non-MITM) eavesdroppers, which is very important with public wifi networks nowadays. Which is why it's strange that self-signed connections are represented to the user as dangerous, while unencrypted connections do not have such a warning even though the former is strictly better.
  - ryanlol 12y ago
    Scenarios where the attacker is restricted to being a non-MITM eavesdropper are pretty rare, public wifi networks aren't an example of such.
    - tveita 12y ago
growse 12y ago
TCP is a transport level protocol. It's job is to get messages from A to B in a way that tries to guarantee delivery (amongst other properties). HTTP is an application level protocol, it's job is to encapsulate messages and commands between two applications that may be remote. We have already built mechanisms that secure traffic on the transport layer (see IPSec) and they actually work well when they're needed/useful. It turns out that right now, securing data on the application layer is much easier / cheaper than trying to do IPSec everywhere. Finally, HTTP is a bit of a special case, because much of the time data delivered over HTTP is code that's going to be executed on a client's machine. If anything, this makes it much more important that the integrity is preserved.
- deleted 12y ago
  [deleted]
deleted 12y ago
[deleted]
kpcyrd 12y ago
There's actually a crypto IP replacement out there: https://github.com/hyperboria/cjdns https://github.com/hyperboria/cjdns
- __david__ 12y ago
  Also djb's http://curvecp.org http://curvecp.org
wtbob 12y ago
Why would that sound zealous? It really would be nice if crypto were part of the foundations of the Internet, rather than applied as window-dressing. It'd require some hard thought about what guarantees are possible and desirable, but that'd be a good thing.

treffer 12y ago

HTTP: here is the length (response header) and here is the payload transfered with checksums (tcp). HTTP has quite good integrity of the data you requested. If you mean HTTPs is great to check if it's coming from the right server (identity/authority) then well, see how well the CA system works and how weak certificates really are (e.g. "Ron was wrong, Whit is right"). You can work around that by doing certificate pinning (see google chrome for example) and stuff like that, but in that case I'd already be better off signing the payload and sending that as part of the response. The scientific institutes of germany worked around all the CA headaches by becoming an intermediate CA (see who signed https://www.pki.dfn.de/ https://www.pki.dfn.de/ ). I'd just expect more intermediate CAs popping up as a result of HTTPs only which will weaken HTTPs even more. (And yes, I'm using https everywhere and would enable https for just about every site, except e.g. for linux iso downloads and alike)

wglb 12y ago
HTTP has quite good integrity of the data you requested Not for the values of "integrity" that include the possibility of intermediate tampering. You have no indication that the request received by the server is the one you sent, nor the response that you received is the one that the server sent.

IanCal 12y ago

> If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place Perhaps I'm not overly concerned with the prospect of someone altering a gif of a cat falling over because someone put ham on its face. People can send me fake letters and post can be intercepted but it's still useful. I'm not saying that security isn't important or that we shouldn't be securing more than we are but the argument that it's vital everything is secured is clearly false. There is traffic that I simply do not care if it is public, and the risk of it being modified (and the consequences if it is) are so low that I think the added time and stress of worrying about it would be more detrimental to me.

growse 12y ago
So if I intercepted kittens.gif and altered the content type to be 'text/javascript' and the body to be a javascript payload that tries to exploit your browser, you're not overly concerned?
- ryanlol 12y ago
  Not really assuming said gif is inside an img tag.
- pdpi 12y ago
  I'd be more worried about my UA not being able to handle that scenario by just refusing to run that javascript payload.
- lewisl9029 12y ago
  A more realistic situation could be a malicious attacker intercepting the cat picture and replacing it with an image containing something that could land the viewer in jail for having any trace of it on his computer (child pornography), and then sending an anonymous tip to law enforcement...
- IanCal 12y ago
  Not really, since javascript loaded into an image tag shouldn't run and I was already following an unknown link to an unknown location coming from an unknown server. The risk that it was intercepted by you is low, and the consequences seem to be low too. You're also skipping straight over the risk that it happens at all, which is a fairly important part of a risk assessment.

edwintorok 12y ago

HTTP is very useful for caching and mirrors for Linux distributions because signatures are checked by package managers outside of the transport protocol.

rlpb 12y ago
And additionally signature verification provides far better security than HTTPS on its own because a compromised mirror cannot compromise the signature.
- rythie 12y ago
  What about confidentiality of the package downloads though? e.g. Snoop the traffic, notice they are downloading a fix, they probably don't have it, automatically attack them before they apply it.
  - vacri 12y ago
    If you had the capability to deliver a prepared attack that quickly, you could probably already just attack them outright.
  - rlpb 12y ago
    HTTPS doesn't protect much from that either. A third party can figure out what you just downloaded based on the download size, since the size of package files are well known. Even if there is some uncertainty between sets of packages it could be inferred from your other downloads, since decisions on what to download are based on known logic (dependency tree, what the victim likely had installed before, etc). I suppose in your case the window would be smaller using HTTPS, as the package downloaded could probably be inferred only after the download is complete. But your method would need automation anyway, so I don't think the difference in timing would really matter in practice. But if you are in the position to automatically attack someone, why wait to see if they are downloading a fix? Why not just try to attack with known recent vulnerabilities anyway?
icebraining 12y ago

pjc50 12y ago

We could really do with an HTTP referent-integrity specification. Just as you specify the size of a linked image, you could add a hash to specify the expected content of a resource. Particularly useful with large linked non-browser resouces. http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/ https://wiki.whatwg.org/wiki/Link_Hashes https://wiki.whatwg.org/wiki/Link_Hashes

ryanlol 12y ago

Except HTTPS does not (currently) solve data integrity issues in real life use cases, getting a certificate issued for someone else's domains is far from difficult... Especially since DNS is still plaintext.

talideon 12y ago
DNSSEC is meant to solve the integrity issue. Now, whether you feel it actually does the job is another matter. Personally, I use it on three domains, one which was done for testing purposes, and the other two because there are DNS records I would like to keep secure from manipulation. It'd be nice if TLSA/DANE was more widely supported, if only to be an additional bar against certificate forgery, but unfortunately it's not. It'd be good if DNS servers other than Knot had decent native support for signing, but they don't in general.
icebraining 12y ago
getting a certificate issued for someone else's domains is far from difficult Is it? Please provide a cert for ycombinator.com. Thanks.
- ryanlol 12y ago
  http://krebsonsecurity.com/2015/02/webnic-registrar-blamed-for-hijack-of-lenovo-google-domains/ http://krebsonsecurity.com/2015/02/webnic-registrar-blamed-f... http://www.zdnet.com/article/revenge-hack-put-5-5-million-domain-names-allegedly-at-risk/ http://www.zdnet.com/article/revenge-hack-put-5-5-million-do... http://www.educause.edu/educause-security-breach-and-password-change-information http://www.educause.edu/educause-security-breach-and-passwor... If you're missing my point, these all of these hacked orgs had the capability to issue SSL certs.
  - icebraining 12y ago
    From what I can tell, they're only resellers, the companies that actually issue the certs are GeoTrust and Symantec. In any case, I know it can and does happen, I just don't agree that it is "far from difficult". Having to hack an SSL provider is out of reach for the vast majority online thieves and casual snoopers.

deskamess 12y ago

jhourcle has addressed this for his type of data with an https side channel for checksums of files available for download. See the response to the comments (also explains why rsync is not appropriate in their system for a specific class of file). jhourcle is not against https, but he/she wants the ability to use http where an exception is needed. The cost of the certificate is negligible, but the ability to keep a fragmented, heterogeneous (age wise) environment is part and parcel of the job, and NO additional funding is being provided to accomplish or operate this under https. From reading the original and the response to other comments, it is apparent to me that jhourcle has thought this through and is only asking for an exception process that they can file for. Just as they do today for systems that are not in compliance (not related to https) for various reasons (ref: comment response).

jasonkester 12y ago

Imagine you've MITM'd funnycatpictures.com. Why, as an end user would I care about the integrity of the funny cat picture you maliciously send me. Provided it is still a funny picture of a cat, your evil http version of the website is still just as useful as the original. There are a lot more funny cat picture sites than banking websites. They are fine using the same protocol they have been since 1995.

MichaelGG 12y ago
Deliver porn, spam, political messages, or illegal content. Or MITM a recipes site and deliver incorrect dietary advice. MITM someone's personal site and add small comments that imply they wish the KKK was a stronger political force, thus discrediting them.
- josteink 12y ago
  Maybe someone even MITMed the comments on this page I'm reading right now, but I'm not going to be awfully worried about that.