I suspect that most folk, such as myself, have blissfully skated past such issues in ignorance because using Node.js to field SSL traffic isn't the standard setup. Instead you run an http.Server - with or without Socket.IO latched to it - behind a websocket-capable, ssl-terminating proxy like HAProxy.
Because you're going to need all the proxy features like failover, clustering, etc, etc, anyway, so why put Node.js right up front?
(Nginx recently added support for websockets, so that's now a viable alternative to HAProxy in this role, but it was aggravating for a while that it wasn't).
Options like Ngnix and haproxy without pound/stud are quite recent and we have not gotten around to trying them out.
In regards to clustering, running socket.io in a cluster with redis store is another world of memory leaking pain. Hopefully socket.io 1.0 with engine.io will solve this but its been nearly released for several months now.
I am now starting to question the value of websockets, long polling is a lot simpler in many ways and robust.
If you want to go with established tech over newer stuff (and the Nginx websocket support is definitely too new for me - give it another 6 months at least), then you can Rube Goldberg a fun setup with Stunnel and Varnish replacing HAProxy.
I haven't had any unpleasant happenings myself with clustering Socket.IO and Redis; that'd be a topic I'd like to see a post on from your lot, given that I'm presently working on the cluster code for a demi-framework for clustered single page Node/Socket apps:
http://www.exratione.com/2012/12/websockets-over-ssl-haproxy...
Because you're going to need all the proxy features like failover, clustering, etc, etc, anyway, so why put Node.js right up front?
(Nginx recently added support for websockets, so that's now a viable alternative to HAProxy in this role, but it was aggravating for a while that it wasn't).