Hacker News Reader

Comment by donavanm | Hacker News Reader

Are there more actual implementation details somewhere? Sounds like selecting the ssl context based on the clients SNI request. This (obviously) would predicate client SNI support, as opposed to anycast IPs or similar.

View on HN

CloudFlare's CEO says that free SSL will use SNI with ipv4 [1] and possibly non-SNI with ipv6 [2]. A CloudFlare engineer has discussed splitting the SSL handshake between servers so their many edge nodes don't need to keep customer secret keys in memory [3]. However, this sounds slightly different than the lazy loading behavior in the blog post.

[1] https://news.ycombinator.com/item?id=7910849

[2] https://twitter.com/eastdakota/status/478369486643658754

[3] http://www.slideshare.net/cloudflare/running-secure-server-s...

Non-SNI over ipv6 seems pretty pointless since anything supporting ipv6 is going to have sni anyway.

Not true; Windows XP supports IPv6 but not SNI.

While that's technically true, XP doesn't enable IPv6 by default, so virtually no one uses it.

Not sure why otterley was down voted. XP is going to exist for a while.

Old android/mobile clients are another case. Mobile operators are moving towards transparent "4 in 6" NAT/encap on their edges. The server would see a layer 3 IPv6 client, while the actual layer 7 client is an old Android/java stack.

I believe you could use node.js or https://github.com/indutny/bud for asynchronously selecting SNI context per request. This is very fast and flexible.

Reply on news.ycombinator.com