Известный поставщик PaaS Heroku предлагает несколько решений проблемы SSL. Один из них - продукт под названием SSL на основе имени хоста
Это не SNI. Они утверждают, что он работает во всех браузерах в любой конфигурации, но имеет другие недостатки, в основном (цитируя документы):
SSL на основе имени хоста не будет работать с корневыми доменами, поскольку он использует псевдоним CNAME для ваших пользовательских доменных имен.
Имя хоста SSL работает только с одним доменом. Например, www.domain.com будет работать, но если в приложение добавить второй сертификат для secure.domain.com, он не будет работать.
В настоящее время наше предложение SSL на основе имени хоста удаляет некоторые заголовки HTTP; это может быть проблемой, когда вашему приложению, например, нужно посмотреть IP-адрес клиента.
Используя это настраиваемое решение для сборки, Heorku может обслуживать несколько сайтов SSL на одном IP-адресе, и, как они утверждают, он будет работать с чем угодно.
Может ли кто-нибудь объяснить техническую сторону этого решения и технологию, лежащую в основе этого продукта?
Это не совсем то, что вы думаете. Heroku не обслуживает несколько сертификатов SSL на одном IP-адресе. Например, если вы выполните nslookup для разных развертываний SSL с именем хоста, вы обнаружите, что каждое из них указывает на разные Amazon ELB. В этом и заключается секретный соус.
Когда клиент запрашивает SSL на основе имени хоста, для него предоставляется ELB, и клиента просят указать CNAME на имя хоста этого ELB. Эти ELB подключаются обратно к сетке маршрутизации Heroku при необходимости.
Надеюсь, это проясняет некоторые вещи. Не стесняйтесь задавать больше вопросов.
Я не знаю, поэтому должен порассуждать. Это может работать в результате взаимодействия между собственными DNS-серверами Heroku и HTTP-серверами. Поток может выглядеть так:
В некоторых сценариях поток может прерваться, особенно при большом количестве запросов для разных сайтов, исходящих с одного IP-адреса (как в случае с клиентами, находящимися за прокси-сервером или шлюзом NAT), но это можно «выровнять» путем распределения запросов. для разных хостов назначения с одного исходного IP-адреса среди множества серверов HTTPS, поэтому у одного сервера HTTPS не будет двусмысленности при принятии решения, какой сертификат выбрать для данного клиента.