Re: [offtopic] ценнник на IP-адреса
>>>>> "AC" == Artem Chuprina <ran@ran.pp.ru> writes:
>>>>> Ivan Shmakov -> debian-russian@lists.debian.org:
>>>>> "EB" == Eugene Berdnikov <bd4@protva.ru> writes:
IS> У меня запущен Nginx на localhost:4443 и Lighttpd на localhost:5443
IS> — каждый со своим ключем и сертификатом.
[…]
IS> PS. Как вариант, заменить localhost выше на 192.168.0.13 и
IS> 192.168.0.37.
[…]
EB> Но можно сделать подобное, если подойти иначе: SNI приводит клиента
EB> на нужный виртуалхост апача, далее проксируете куда нужно.
EB> Разумеется, ключи и сертификаты виртуалхостов нужно передать Апачу,
EB> иначе он не сможет провести хэндшейк,
IS> Именно так. Однако, тем самым, в «цепи доверия» появляется «лишняя
IS> сущность» — администратор proxy.
AC> … он же, по совместительству, root того хоста, на котором крутятся
AC> бэкэнды (поскольку они показываются на localhost). То есть имеет
AC> непосредственный доступ к секретным ключам от сертификатов
AC> бэкэндов. Ты все еще хочешь ему не доверять?
Я вернул фрагмент исходного сообщения выше.
BTW, при использовании DNAT, localhost:XXX может также оказаться
«не вполне локальным.»
[…]
AC> Кстати, я сейчас не то чтобы вспомню точно протокол TLS, а тем
AC> более - где там SNI появляется. Не исключено, что можно пробросить
AC> коннект. Явно указание имени хоста должно появиться в клиентском
AC> запросе ДО начала использования ключей и по-хорошему, даже
AC> конкретных шифрсьютов (потому что сертификаты-то разные), то есть
AC> буквально в hello-пакете. В этот момент шифрование еще не пошло, и
AC> прокинуть соединение, в общем, можно.
Не исключено.
Не удивлюсь, однако, если такой трюк пока еще нигде не
реализован. (Хотя в GnuTLS, пожалуй, загляну при случае.)
--
FSF associate member #7257
Reply to: