Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Новый олимпийский сайт “Сочи-2014” и HTTPS
Новый сайт Sochi2014.com вполне логично размещён на мощностях Akamai (один из крупнейших мировых провайдеров услуг CDN) – это хорошо. Но вот с HTTPS повторяется типичная для Akamai история: при попытке безопасного соединения с https://www.sochi2014.com/ – серверы отдают “провайдерские” SSL-сертификаты, выпущенные не для sochi2014.com, а для имён вроде *.akamaihd.net, a248.e.akamai.net и прочих. В результате – имеем в браузере предупреждение системы безопасности, что уже не очень хорошо.
Проблема, кстати, весьма старая, и Akamai её, похоже, так и не поправил.
Адрес записки: https://dxdt.blog/2014/01/11/6526/
Похожие записки:
- LLM в разработке и тестировании программ
- Один сценарий интернет-измерений и поле SNI HTTPS/TLS
- "Случайные пакеты" как транспорт
- Предварительные результаты расследования катастрофы AI171
- Техническое: обновления на тестовом сервере TLS 1.3
- Удаление аккаунтов GoDaddy
- Домены верхнего уровня, реестры и администраторы
- Теги ключей DNSSEC: продолжение
- SPF/DKIM и ложный текст от LLM на "Хабре"
- Поддержка STARTTLS сервисом audit.statdom.ru
- Разбор ситуации с неавторизованными сертификатами для 1.1.1.1 от Cloudflare
Новый 
Комментарии читателей блога: 2
1 <t> // 11th January 2014, 21:51 // Читатель Дмитрий Белявский написал:
А ты представляешь, как корректно CDN должен жить с HTTPS? Распихать сертификат повсюду? Как-то некузяво с точки зрения безопасности, ИМХО.
2 <t> // 11th January 2014, 22:37 // Александр Венедюхин:
Я бы предложил распихать сертификат, потому что – куда деваться? В принципе, можно поставить отдельные прокси для SSL, и держать ключи/сертифкаты там. Но, с другой стороны, можно и просто не отвечать по HTTPS.