Dara Hayes The key pieces to using websockets with classic ELB's are:

1. websockets are implemented as sort of an extension to HTTP, they use a standard HTTP request for compatibility alongside standard HTTP traffic on the same port, but add an additional header to "upgrade" the HTTP request to be a websocket
2. Classic ELB's don't strictly follow the full HTTP RFC spec, in this case, the upgrade header which websockets require isn't supported with the Layer 7 (HTTP/HTTPS) listeners, hence they need to be changed to layer 4 (TCP/SSL) instead.
3. SSL Termination with Certificates on the ELB only work with Layer 7 listeners, so to still have encrypted traffic with Layer 4, SSL needs to be implemented by the backend instances
4. A classic ELB can provide source address info via X-Forwarded-For header with Layer 7 listeners, but you can't add an HTTP header at Layer 4 because HTTP itself doesn't exist until Layer 7. Therefore, proxy protocol needs to be enabled on the ELB for all backend instance ports (only possible via CLI and not even visible from the Web console). This allows source address information to be passed to the backends within Layer 4.
5. The backend instances need to know to get the client's source address from proxy protocol info instead of using the source address of the TCP packets which would be the IP address of the load balancer.

The above sounds really complex but could be summarized as:
Classic ELB's implement everything needed at layer 4 for websockets, but need to rely on backend instances to support the layer 7 stuff.

I don't know of any reference which covers all of the pieces, though I honestly don't know why there wouldn't be one. I know about all of the parts because of past investigations I have done for various FHOPS/RHMAP tickets involving support for client certificates, websockets, security, etc.