5 ms·

Ridiculously conservative middleboxes are why we can't have nice things and why we need to encrypt all new protocols, security properties aside.

jlgaddis 10y ago
[ off-topic comment deleted ]
- kbart 10y ago
  Probably you have already (mis)clicked (down)vote button on this comment before. It's easy to do accidentally, especially on touchscreen.
  - jlgaddis 10y ago
    I was pretty sure that wasn't it. I noticed it as soon as I first saw the comment. That's the simplest explanation, though, so that's probably what happened. Oh well.
DanielDent 10y ago
This is precisely the conclusion Google reached and has used as they work on QUIC. Even protocol state (equivalents of TCP FIN/SYN/etc) is encrypted, to ensure that middleboxes don't get ideas about what the protocol is 'supposed' to do - ideas which make it hard to change the protocol in the future.
- CapacitorSet 10y ago
  It is really sad that one reason why QUIC encrypts protocol states is to prevent excessively eager middleboxes from meddling with the traffic.
peterwwillis 10y ago
Actually, no, that would just make everything more difficult. Browsers need to start coming to terms with the fact that they do not get do dictate how www networking operates for every organization around the world. There are hundreds of thousands of organizations that need inspection and caching and proxying of internal www traffic. That all protocols should disallow or frustrate this disregards real needs of users and organizations. Further still, if protocols can't be designed to be implemented easily or to allow for implementation bugs or lack of features, it's a crap protocol or application. Middleware will always be necessary, and encryption really shouldn't change the requirements of how middleware needs to work with a protocol.
- kibwen 10y ago
  Then those organizations are free to not use encryption-friendly protocols for internal resources. Furthermore, those companies are free to fork Chromium or Firefox and distribute their own browser that renders these protocols toothless. IOW, it's completely fair to argue that users might not have a universal right to encryption, but it's just as legitimate to argue that browser vendors have no obligation to enable the trivial circumvention of encryption. If the software doesn't work for your needs, then stop using the software.
  - peterwwillis 10y ago
    No they aren't, encryption is still required for internal transactions as well as working with external partners. And fork a browser? Are you nuts? Nobody made that argument. But browser makers have an obligation to keep the world wide web usable. If it's not usable, say goodbye to dot com companies selling services to businesses, which aside from advertising revenue (and the hopes and dreams of venture capitalists) is the only way they survive. The only reasonable alternative if you start locking out legitimate business use cases of traffic inspection is to abandon the web and start making proprietary native applications and protocols like back in the old days. This is bad for users and bad for business. It's not like it's even hard to support these use cases while maintaining user security! Browsers just totally suck at interfacing with a dynamic user role. Better UX and a more flexible protocol would solve this, but nobody wants to make browsers easier to use (more the opposite)
    - kibwen 10y ago
      > No they aren't, encryption is still required for internal transactions as well as working with external partners. Then continue to use the encryption that exists today. After all, your concern is for future standards that make encryption stronger. > And fork a browser? Are you nuts? A lone user forking a browser would be nuts. A company that's already willing to pay through the nose for MITM proxies can afford to fund a minor browser fork. Indeed, if this use case is as important as you suspect, then you ought to start a company that sells customized browsers for exactly this purpose. Think about what site you're on; where's your entrepreneurial spirit? :) > But browser makers have an obligation to keep the world wide web usable. Usable for whom? Between users (who need strong encryption), websites (who need strong encryption), and corporate intranets (who need to snoop), whose needs ought to be prioritized? > abandon the web and start making proprietary native applications The web emerged from a world where all applications were native and proprietary, I don't think any browser vendor is losing sleep over this possibility. > Browsers just totally suck at interfacing with a dynamic user role. Again, sounds like there's demand for a new browser then. :) > nobody wants to make browsers easier to use (more the opposite) Why is that?

jlgaddis 10y ago

[ off-topic comment deleted ]

kbart 10y ago
Probably you have already (mis)clicked (down)vote button on this comment before. It's easy to do accidentally, especially on touchscreen.
- jlgaddis 10y ago
  I was pretty sure that wasn't it. I noticed it as soon as I first saw the comment. That's the simplest explanation, though, so that's probably what happened. Oh well.

DanielDent 10y ago

This is precisely the conclusion Google reached and has used as they work on QUIC. Even protocol state (equivalents of TCP FIN/SYN/etc) is encrypted, to ensure that middleboxes don't get ideas about what the protocol is 'supposed' to do - ideas which make it hard to change the protocol in the future.

CapacitorSet 10y ago
It is really sad that one reason why QUIC encrypts protocol states is to prevent excessively eager middleboxes from meddling with the traffic.

peterwwillis 10y ago

Actually, no, that would just make everything more difficult. Browsers need to start coming to terms with the fact that they do not get do dictate how www networking operates for every organization around the world. There are hundreds of thousands of organizations that need inspection and caching and proxying of internal www traffic. That all protocols should disallow or frustrate this disregards real needs of users and organizations. Further still, if protocols can't be designed to be implemented easily or to allow for implementation bugs or lack of features, it's a crap protocol or application. Middleware will always be necessary, and encryption really shouldn't change the requirements of how middleware needs to work with a protocol.

kibwen 10y ago
Then those organizations are free to not use encryption-friendly protocols for internal resources. Furthermore, those companies are free to fork Chromium or Firefox and distribute their own browser that renders these protocols toothless. IOW, it's completely fair to argue that users might not have a universal right to encryption, but it's just as legitimate to argue that browser vendors have no obligation to enable the trivial circumvention of encryption. If the software doesn't work for your needs, then stop using the software.
- peterwwillis 10y ago
  No they aren't, encryption is still required for internal transactions as well as working with external partners. And fork a browser? Are you nuts? Nobody made that argument. But browser makers have an obligation to keep the world wide web usable. If it's not usable, say goodbye to dot com companies selling services to businesses, which aside from advertising revenue (and the hopes and dreams of venture capitalists) is the only way they survive. The only reasonable alternative if you start locking out legitimate business use cases of traffic inspection is to abandon the web and start making proprietary native applications and protocols like back in the old days. This is bad for users and bad for business. It's not like it's even hard to support these use cases while maintaining user security! Browsers just totally suck at interfacing with a dynamic user role. Better UX and a more flexible protocol would solve this, but nobody wants to make browsers easier to use (more the opposite)
  - kibwen 10y ago
    > No they aren't, encryption is still required for internal transactions as well as working with external partners. Then continue to use the encryption that exists today. After all, your concern is for future standards that make encryption stronger. > And fork a browser? Are you nuts? A lone user forking a browser would be nuts. A company that's already willing to pay through the nose for MITM proxies can afford to fund a minor browser fork. Indeed, if this use case is as important as you suspect, then you ought to start a company that sells customized browsers for exactly this purpose. Think about what site you're on; where's your entrepreneurial spirit? :) > But browser makers have an obligation to keep the world wide web usable. Usable for whom? Between users (who need strong encryption), websites (who need strong encryption), and corporate intranets (who need to snoop), whose needs ought to be prioritized? > abandon the web and start making proprietary native applications The web emerged from a world where all applications were native and proprietary, I don't think any browser vendor is losing sleep over this possibility. > Browsers just totally suck at interfacing with a dynamic user role. Again, sounds like there's demand for a new browser then. :) > nobody wants to make browsers easier to use (more the opposite) Why is that?