5 ms·

You shouldn't rely on any protocol like this being 'secure'. You should have other security in other places. So I don't think that's a valid reason really. It'

by axod 16y ago

You shouldn't rely on any protocol like this being 'secure'. You should have other security in other places. So I don't think that's a valid reason really. It's possible to support both, and that's what I'll personally be doing with my own web server. The changes I've seen don't add any obvious extra security as such, just make it a little more difficult. edit: Please give clear references when you say "Fundamentally insecure protocol". That's pretty much totally unfounded. What type of security are you talking about?

jerf 16y ago
"Please give clear references when you say "Fundamentally insecure protocol". That's pretty much totally unfounded. What type of security are you talking about?" Directly from the article: "introduces nonce-based challenge-response to protect from cross protocol attacks." In my experience, when people identify a possible security attack it's usually correct. (The solution can be another matter, but I'm not looking at this enough to have even an uninformed position.) The problem the sort of people working out a protocol like this have is missing ones that are possible, not pointing out ones that don't exist. If you're comfortable with unnecessarily insecure lower layers, more power to you. Don't expect plaudits from me. Or expect me to be taking security advice from you after casually disregarding things like "security in depth".
- axod 16y ago
  The original version of the protocol was already pretty strict. It required exact responses, played in exactly the correct order in order for a connection to be established. All the new version does, is send over some obscure challenge data (generate a random number, then insert random characters into it????). Then it expects a response from the server with the value md5(challenge). That does indeed get rid of a class of cross protocol attacks, but it's a ridiculous edge case as far as I can see. Previously you may have been able to find some server (non HTTP), that you could connect to, somehow get it to respond with the correct HTTP headers in exactly the right order, and continue. Then exploit it - send spam email, etc etc That's pretty unlikely. Now, you'd have to get that server to respond with the md5 response, which is fairly impossible. BUT. The security here is in Browser->"Some non HTTP server being tricked" - eg something I don't care about too much. Make your "non HTTP server" more secure. For example see the recent exploit against freenode earlier this year, where they allowed connections from an automated HTTP POST in the Firefox browser - the ircd just ignored any HTTP stuff and happily connected users to spam away. The fix wasn't to update the HTTP protocol or firefox, it was to patch the ircd so it actually checks what protocol the client is speaking (And also PING/PONG checks etc) So, your premise that the original spec is somehow insecure to use within a browser->webserver context, is completely incorrect.

by axod 16y ago

jerf 16y ago

"Please give clear references when you say "Fundamentally insecure protocol". That's pretty much totally unfounded. What type of security are you talking about?" Directly from the article: "introduces nonce-based challenge-response to protect from cross protocol attacks." In my experience, when people identify a possible security attack it's usually correct. (The solution can be another matter, but I'm not looking at this enough to have even an uninformed position.) The problem the sort of people working out a protocol like this have is missing ones that are possible, not pointing out ones that don't exist. If you're comfortable with unnecessarily insecure lower layers, more power to you. Don't expect plaudits from me. Or expect me to be taking security advice from you after casually disregarding things like "security in depth".

axod 16y ago
The original version of the protocol was already pretty strict. It required exact responses, played in exactly the correct order in order for a connection to be established. All the new version does, is send over some obscure challenge data (generate a random number, then insert random characters into it????). Then it expects a response from the server with the value md5(challenge). That does indeed get rid of a class of cross protocol attacks, but it's a ridiculous edge case as far as I can see. Previously you may have been able to find some server (non HTTP), that you could connect to, somehow get it to respond with the correct HTTP headers in exactly the right order, and continue. Then exploit it - send spam email, etc etc That's pretty unlikely. Now, you'd have to get that server to respond with the md5 response, which is fairly impossible. BUT. The security here is in Browser->"Some non HTTP server being tricked" - eg something I don't care about too much. Make your "non HTTP server" more secure. For example see the recent exploit against freenode earlier this year, where they allowed connections from an automated HTTP POST in the Firefox browser - the ircd just ignored any HTTP stuff and happily connected users to spam away. The fix wasn't to update the HTTP protocol or firefox, it was to patch the ircd so it actually checks what protocol the client is speaking (And also PING/PONG checks etc) So, your premise that the original spec is somehow insecure to use within a browser->webserver context, is completely incorrect.