[jaywalk]

Except that without SSL, some JavaScript could be injected to grab the password completely outside of the RSA encryption. So assuming there is already a MITM who wants the password, all you'd be doing is making his attack slightly more complicated.

[mlyle]

Those geographically distributed SSL-terminating load balancers could still conduct such an attack, SSL or not.

[jaywalk]

Yep. If any sort of MITM attack was their motivation for this, they didn't really think it through.

[crdrost]

The passive collection case is presumably enough to justify it. Like, after those folks who were sniffing Facebook and MySpace cookies on unsecured WiFi routers were caught, I can imagine pushing for something like this, "just to force them to single us out and perform an active attack on us, which most passive WiFi sniffers are likely not willing to do," or so.

Another separate derivation would be: “we log every single call. period. I will take on whatever cost to have that oversight of my system.” Well that's problematic, dr. boss, because several calls have PII in them and we want to be careful with how we store that. "OK, we encrypt the PII in-transit so that our logging doesn't have access to it." Well OK but our “log everything” philosophy is now also logging the keys that it was encrypted with, which the client has to fetch. Every call, right? So we are still storing the PII for any hacker to decrypt. "Well, let’s use asymmetric encryption so that this information is not sufficient to decrypt.” OK, but I can still connect information about how you were playing this game at this time, to how you were playing that game at that time. The logs contain that second-order PII that exists in correlations because you use a deterministic process to encrypt. (And at this point the obvious thing to do is a nondeterministic encryption process but you can also just rotate the keys periodically to make this sort of correlation only work over very short timescales.)

Just saying, HTTPS assumes that the problem is insecure channels between secure endpoints when the problem can also be at one or the other endpoint. Like another person said, you might also decrypt right before a load balancer and then route the sensitive data to some other data center because it has lower overall load, etc. etc.

[noobquestion81]

Disagree. Theres a big difference between passive and active collection attacks. If the stakes are a site-wide password breach, it can make sense to eliminate passive attacks specifically.

Remember, sometimes breaches are caused because someone at the POP left HTTP parameter logging enabled.

[rplnt]

Support logging without SSL meaning the backend accepts it, not that the login page is ever served like that. Remember that they have desktop and mobile applications for various platforms, where the signing would be part of the application. Although the keys...

[merb]

> Except that without SSL, some JavaScript could be injected to grab the password completely outside of the RSA encryption. So assuming there is already a MITM who wants the password, all you'd be doing is making his attack slightly more complicated.

how does ssl prevent you from that? it doesn't.

[drodgers]

An SSL client will cryptographically verify the authenticity of all messages recieved from Valve's servers, so the resulting webpage can't have any Javascript injected by someone without Valve's private key.

Without this kind of authentication, encrypting the connection would be pointless.

[merb]

well it depends an administrator of an org can actually inject javascript without intercepting the http response stream.

[woodrowbarlow]

the assumption is that the javascript would be injected into the page on its way from steam servers to your browser. ssl would prevent that. i think you're imagining a case where a user has (for example) installed a malicious browser extension. ssl would not help with that.

[ROARosen]

True, except that in Steam's specific case, they are actually using SSL.