Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Socket.IO and WebSocket do not provide underlying connection information (like the certificate or public key of the SSL/TLS channel), and I'm trying to understand the reasoning.

The context for this question is a side loaded web application that wants to query the certificate or public key of its underlying connection. The query would be used for certificate or public key pinning. Here, the side loading provides a trusted distribution channel so tampering with HTML/CSS/Javascript is not a concern or threat.

Those who claim its not needed state (1) the platform performs checks so its not needed; (2) CSS or Javascript could use the server's certificate or public key to track users, so its a potential leak; and (3) its inefficient, so its not welcomed.

I think there are a few problems with the arguments. First, we've seen a number of problems in the past, like Diginotar and recently Turkey tampering with DNS. The platform/browser did not detect the problems (sans Chrome due to pinning), so the browsers are not performing the correct checks. I understand the browser cannot know these things (its a "feature" or limitation in the security model), and its the reason I want the apps under my purview to do it.

Second, malware wants to gather and egress data. So the most dangerous parts of the Socket.IO and WebSocket API are open and write. I doubt the ability to query a server's certificate or public key exceeds the risk of open and write.

Third, I'm fairly certain there are better vectors for CSS or Javascript to track users or their browsing (like CSS tracking the color change on a visited link), so I don't consider it an immediate or high priority threat. If it is a threat, I feel the benefits of channel hardening outweigh the possible leak. (Especially in the post-Snowden era).

Finally, regarding efficiency, I have to defer to Dr. Jon Bentley: "If it doesn't have to be correct, I can make it as fast as you'd like it to be". I imagine that includes all kinds of clever optimizations, like eNull when using TLS.

Here's my closed-ended question: is it really considered a potential leak to allow Javascript to ask for the server's certificate? Does the fear of a "leak" of the server's certificate really outweigh the benefits of channel hardening and pinning?

Here's the open-ended question: what don't I understand correctly or what am I missing? I feel like there's a major disconnect between what I want and expect, and what the folks writing the standards are willing to provide.


For completeness, "web application" is the generic term and would cover, for example, Sys Apps, Hosted Apps, Chrome Apps, Packaged Apps, Installable Apps, etc. It would not cover other web apps, like Bookmarked Apps because that would require a fetch.


Related: another good question on WebSocket security: Elaborate websockets security, but it does not discuss missing features.

share|improve this question

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.