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.
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
write. I doubt the ability to query a server's certificate or public key exceeds the risk of
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 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.