<div dir="ltr"><div class="gmail_extra"><span class="im" style="font-size:12.8000001907349px">On Sun, Aug 2, 2015 at 9:54 AM, Carlo Contavalli <span dir="ltr"><<a href="mailto:ccontavalli@gmail.com" target="_blank">ccontavalli@gmail.com</a>></span> wrote:<br></span><span class="im" style="font-size:12.8000001907349px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello,<br><br>haven't seen many conversations or much noise about SRP, from<br><a href="http://srp.stanford.edu/" rel="noreferrer" target="_blank">http://srp.stanford.edu/</a> on this mailing list.<br><br>By a quick reading, and by peeking at the implementation, it provides<br>strong mutual authentication of both client and server through a<br>"shared secret", which is stored as a one way hash on the server, and<br>never exchanged on the wire.<br></blockquote><div><br></div></span><div style="font-size:12.8000001907349px">Yes. Wikipedia article <a href="https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol" target="_blank">https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol</a> </div><div style="font-size:12.8000001907349px">also has a reasonable explanation on how they work. There is also an RFC 5054</div><div style="font-size:12.8000001907349px">that plops SRP on top of TLS.</div><span class="im" style="font-size:12.8000001907349px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Eg, if used with ssh, checking the fingerprint when connecting would<br>be significantly less relevant, the fact that the server can establish<br>an encrypted session at all proves that the server knows a hash of the<br>shared secret.<br></blockquote><div><br></div></span><div style="font-size:12.8000001907349px">But, with ssh, or protocols like ssh, session is established per TCP </div><div style="font-size:12.8000001907349px">connection. You wouldn't ask the user the password every time an HTTP(s)</div><div style="font-size:12.8000001907349px">connection is established.</div><span class="im" style="font-size:12.8000001907349px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Has drawbacks - but certainly sounds like an improvement compared to<br>existing protocols?<br><br>Are there / why are not similar technologies used for web?<br></blockquote><div><br></div></span><div style="font-size:12.8000001907349px">There certainly are for the web. Not so much for HTTP(s) though. You can't</div><div style="font-size:12.8000001907349px">reasonably (from the UE perspective) implement SRP/ZKP for HTTP because</div><div style="font-size:12.8000001907349px">it needs to span multiple HTTP requests. The full SRP web solutions do require</div><div style="font-size:12.8000001907349px">javascript (or other) code to retrieve any protected data (there are solutions</div><div style="font-size:12.8000001907349px">that only check the password, after which it's standard HTTP session)</div><span class="im" style="font-size:12.8000001907349px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I see two separate needs x509 certificates and TLS typically try to address:<br>1) establishing the identity of a site you connect to.<br>2) maintaining privacy and preventing mangling of the data exchanged.<br><br>If I think about my typical workflow, ... x509 and certificates would<br>still play a role the first time I end up on a site.<br><br>Eg, the first time I go to <a href="http://uber.com/" rel="noreferrer" target="_blank">uber.com</a>, or first time I register to use<br>my health plan benefits online, I would check that the certificate<br>matches who the site claims to be.<br><br>But from then on... once registered, and once I have a password, SRP<br>would allow me to establish that the remote end is who they claim to<br>be based on their ability to prove that they know a hash of my<br>password, the certificate would just be an additional protection?<br></blockquote><div><br></div></span><div style="font-size:12.8000001907349px">If the X509 certificate checks out that just means nobody stole the private</div><div style="font-size:12.8000001907349px">key of the holder, or a CA you trust. If the SRP checks out, that means that the</div><div style="font-size:12.8000001907349px">server has the verifier code derived from your password. So in case of</div><div style="font-size:12.8000001907349px">the password database breach, it would be very hard to derive your password,</div><div style="font-size:12.8000001907349px">but still as easy to impersonate the server. Though they won't get your password</div><div style="font-size:12.8000001907349px">even if you give it to the impersonator.</div><span class="im" style="font-size:12.8000001907349px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Seems like a significant improvement over what we have today? Reducing<br>exposure, and need to trust certification authorities?<br></blockquote><div><br></div></span><div style="font-size:12.8000001907349px">If you don't use PKI, then you'd have problems trusting whom to establish</div><div style="font-size:12.8000001907349px">the passwords with in the first place.</div><span class="im" style="font-size:12.8000001907349px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">For example: a rogue certificate authority creates a false uber /<br>false health plan management site. Or a rogue certificate is installed<br>on my laptop. I try to login after this fake has been created, ... I<br>would not be able to login?</blockquote><div><br></div></span><div style="font-size:12.8000001907349px">Your client must terminate the connection if the server's proof doesn't</div><div style="font-size:12.8000001907349px">check out, or if it can't decrypt the data from the server.</div><span class="im" style="font-size:12.8000001907349px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">or notice immediately? Or if they proxy my<br>connection acting as a MITM, they would not be able to decrypt my<br>data?<br></blockquote><div><br></div></span><div style="font-size:12.8000001907349px">Yes, neither fake servers no MITM can get into your data unless they have the verifier.</div><div style="font-size:12.8000001907349px"> <br></div><blockquote class="gmail_quote" style="font-size:12.8000001907349px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Opinions?<br></blockquote><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">SRP really helps in:<br>- preventing password from ever being transmitted</div><div style="font-size:12.8000001907349px">- preventing guessing the password even if the password is really simple</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Besides it's ability to encrypt communications, it in no way deprecates any of the </div><div style="font-size:12.8000001907349px">functionality of the PKI.</div><div style="font-size:12.8000001907349px"><br></div>
</div></div>