4 ms·

Building a protocol over HTTP has the added benefit of making security easy. HTTP+TLS has a lot more eyeballs than protocols on lower levels. Most protocols on

Building a protocol over HTTP has the added benefit of making security easy. HTTP+TLS has a lot more eyeballs than protocols on lower levels. Most protocols on layer 3 and below weren't designed with security as a priority. If you are building a domain specific protocol, it's a lot easier to build on top of one which already has a good security story backed by a triumvirate of internet unicorns, than trying to re-invent the whole public key dance on a homebrewed setup.

paulddraper 8y ago
SSL/TLS with other protocols have a lot of usage too. SFTP/FTPS, SSH, SMTPS, etc.
- BTeam 8y ago
  SSH is a cryptographic network protocol that doesn't use SSL/TLS.
  - paulddraper 8y ago
    My bad. I should have said SSL/TLS/SSH. * SFTP/FTPS (SSH) * SSH (SSH) * SMTPS (SSL, TLS)
    - tzahola 8y ago
      Still wrong. FTPS is vanilla FTP over TLS.
      - eganist 8y ago
        > Still wrong You know that thing that gives security practitioners a bad reputation with engineers? You're doing it. As opposed to this, why not something more like "it's not uncommon for these two to be confused, but FTPS is FTP over TLS and isn't interchangeable with SFTP"?
        meeeh 8y ago
        Because it's longer? Pardon my foreign mind, but I do not understand, why you are offended by a simple short and valid statement nor why you are differentiating between "security pratitioners" and "engineers".
- tzahola 8y ago
  FTPS is FTP over TLS. However SSH and SFTP has nothing to do with TLS.
tzahola 8y ago
You only need TLS for that. HTTP adds nothing security-wise.
- paulddraper 8y ago
  It adds Authorization, WWW-Authenticate, Proxy-Authentication, Proxy-Authenticate, Cache-Control, but those aren't even used that consistently.
eftychis 8y ago
As others have commented (adding a couple of notes): HTTP and HTTP/2 use TLS for security which is over TCP (reliable transfer requirement). Nothing more, nothing less. Sure layer 3 and below have different considerations (reliability). Layer 4 (say TCP) covers the end to end security. It would be nice if HTTP/2 added something security wise, as was discussed, but the committee was conservative. Thus I am not sold to this argument. The rich functionality of HTTP and multiplexing of HTTP/2 sound appealing (sections 3.1-3.4), if you are building an API. If not I would not rush to that conclusion. Why would I want to add the necessity for streaming if I am doing a over the network video compression and do not care about reliability or want to skip frames for instance? I guess it is IETFs job to standardize stuff so that is what they do -- for a hammer everything is a nail, right? P.S. I skimmed it, so perhaps it is worth a read, but nothing caught my eye really.
geocar 8y ago
> Building a protocol over HTTP has the added benefit of making security easy Not to take away from that, it's also very easy to get wrong as well. - Not doing CA verification check[1] - No alerts/monitoring of new certificates used by the IDP - No verification on certificate-transparency of new certificates used by the IDP - No online CRL checking If you do not do these things, then your application-on-HTTP is insecure. Remember that it's very easy to get a new certificate if you can break IP either by MITMing the server or by BGP takeover of some space near the CA. Both of these things have happened. If there's a way you can detect incorrect implementations, then blacklist them. For example, I use OAuth2 in my own systems, but I require clients retry (by randomly failing during onboarding) and implement fuzzing whereby the client_secret is invalidated if they accept an invalid certificate. [1]: http://web.archive.org/web/20120317165131/http://forum.developers.facebook.net/viewtopic.php?pid=258460 http://web.archive.org/web/20120317165131/http://forum.devel...
tialaramex 8y ago
Those eyeballs almost all belong to the Web Browser vendors who are almost exactly a proxy for the Operating System vendors, you mention them as three "unicorns", though it's hard to pick three, I have an easier time saying four, or maybe five. Specifically they are Google's Chrome (Android), Microsoft's IE/Edge (Windows), Apple's Safari (iOS/ macOS) leaving only Mozilla's Firefox (standing in for the Free Unixes). If there's a fifth it's Oracle, as custodians of Java. A tremendous weight ends up resting on the shoulders of these vendors, all of them based on the US West Coast, and it's not as though this a power _seized_ by them, it's more something everybody else shirked.

paulddraper 8y ago

SSL/TLS with other protocols have a lot of usage too. SFTP/FTPS, SSH, SMTPS, etc.

BTeam 8y ago
SSH is a cryptographic network protocol that doesn't use SSL/TLS.
- paulddraper 8y ago
  My bad. I should have said SSL/TLS/SSH. * SFTP/FTPS (SSH) * SSH (SSH) * SMTPS (SSL, TLS)
  - tzahola 8y ago
    Still wrong. FTPS is vanilla FTP over TLS.
    - eganist 8y ago
      > Still wrong You know that thing that gives security practitioners a bad reputation with engineers? You're doing it. As opposed to this, why not something more like "it's not uncommon for these two to be confused, but FTPS is FTP over TLS and isn't interchangeable with SFTP"?
      - meeeh 8y ago
        Because it's longer? Pardon my foreign mind, but I do not understand, why you are offended by a simple short and valid statement nor why you are differentiating between "security pratitioners" and "engineers".
tzahola 8y ago
FTPS is FTP over TLS. However SSH and SFTP has nothing to do with TLS.

tzahola 8y ago

You only need TLS for that. HTTP adds nothing security-wise.

paulddraper 8y ago
It adds Authorization, WWW-Authenticate, Proxy-Authentication, Proxy-Authenticate, Cache-Control, but those aren't even used that consistently.

eftychis 8y ago

As others have commented (adding a couple of notes): HTTP and HTTP/2 use TLS for security which is over TCP (reliable transfer requirement). Nothing more, nothing less. Sure layer 3 and below have different considerations (reliability). Layer 4 (say TCP) covers the end to end security. It would be nice if HTTP/2 added something security wise, as was discussed, but the committee was conservative. Thus I am not sold to this argument. The rich functionality of HTTP and multiplexing of HTTP/2 sound appealing (sections 3.1-3.4), if you are building an API. If not I would not rush to that conclusion. Why would I want to add the necessity for streaming if I am doing a over the network video compression and do not care about reliability or want to skip frames for instance? I guess it is IETFs job to standardize stuff so that is what they do -- for a hammer everything is a nail, right? P.S. I skimmed it, so perhaps it is worth a read, but nothing caught my eye really.

geocar 8y ago

> Building a protocol over HTTP has the added benefit of making security easy Not to take away from that, it's also very easy to get wrong as well. - Not doing CA verification check[1] - No alerts/monitoring of new certificates used by the IDP - No verification on certificate-transparency of new certificates used by the IDP - No online CRL checking If you do not do these things, then your application-on-HTTP is insecure. Remember that it's very easy to get a new certificate if you can break IP either by MITMing the server or by BGP takeover of some space near the CA. Both of these things have happened. If there's a way you can detect incorrect implementations, then blacklist them. For example, I use OAuth2 in my own systems, but I require clients retry (by randomly failing during onboarding) and implement fuzzing whereby the client_secret is invalidated if they accept an invalid certificate. [1]: http://web.archive.org/web/20120317165131/http://forum.developers.facebook.net/viewtopic.php?pid=258460 http://web.archive.org/web/20120317165131/http://forum.devel...

tialaramex 8y ago

Those eyeballs almost all belong to the Web Browser vendors who are almost exactly a proxy for the Operating System vendors, you mention them as three "unicorns", though it's hard to pick three, I have an easier time saying four, or maybe five. Specifically they are Google's Chrome (Android), Microsoft's IE/Edge (Windows), Apple's Safari (iOS/ macOS) leaving only Mozilla's Firefox (standing in for the Free Unixes). If there's a fifth it's Oracle, as custodians of Java. A tremendous weight ends up resting on the shoulders of these vendors, all of them based on the US West Coast, and it's not as though this a power _seized_ by them, it's more something everybody else shirked.