Уберите часть «аутентификации» и просто поговорите о части шифрования, пожалуйста! (Аутентификация - другая проблема.)
Пример: подключение к http://ipv6.google.com можно зашифровать через HTTPS следующим образом: https://ipv6.google.com/ (Если у вас нет IPv6, вы можете попробовать IPv4: https://www.google.com)
Можно ли запрограммировать веб-серверы, а также браузеры для поддержки, например,
http-over-ipsec://ipv6.google.com
как лучше и безопаснее заменить https?
Проблема с шифрованием не в протоколе (будь то SSL, TLS или IPSec), а в загрузке. SSL и TLS полагаются на доверенных (для определенного значения «доверенного») третьих лиц, которые удостоверяют, что определенный ключ шифрования принадлежит определенному веб-сайту. Иначе как мы узнаем, действительно ли мы разговариваем с нужным сервером? Соединение могло быть взломано. Аутентификация всегда важна (всегда для клиента, аутентифицирующего сервер, а иногда также для сервера, аутентифицирующего клиента). Без аутентификации кто угодно может заявить, что он ipv6.google.com.
С ростом поддержки DNSSEC мы получаем лучшие варианты начальной загрузки: DANE (RFC 6698) и ключи IPSec в DNS (RFC 4025). Оба они позволяют использовать DNS (который должен быть защищен с помощью DNSSEC) для начальной загрузки шифрования. DNS сообщает клиенту о сертификате, который будет использоваться, и нам больше не нужно полагаться на третьих лиц.
Убедитесь, что DNSSEC получает широкое распространение и это становится возможным. В противном случае мы застрянем в нынешней сложной и дорогой системе сторонних центров сертификации ...
Нет, IPsec не может и не будет заменять HTTPS, потому что они фактически являются яблоками и апельсинами, и вот почему:
IPsec работает на сетевом уровне и явно согласовывается через IKE - обе конечные точки должны согласовать схему ключей, режим работы и ряд других параметров, которые затем устанавливаются во все, что отвечает за стек IP (v6) (обычно ядро операционной системы).
* IPsec предназначен для защиты всего канала (или каналов) связи в течение длительного периода, в отличие от простой настройки короткого сеанса, обмена данными и его разрыва.
Следовательно, IPsec просто плохо масштабируется для тех времен жизни, которые обычно возникают у HTTPS (т.е. повторяющиеся, непродолжительные соединения), не говоря уже о том, что он явно полагается на сам стек IP, что делает его реализацию в приложении проблематичной и проблема безопасности, поскольку настройка параметров IPsec обычно является привилегированной операцией, требующей доступа root / администратора.
HTTPS, с другой стороны, более конкретно, SSL / TLS работает на основе приложения (например, вашего веб-браузера), имеющего заранее определенный список органов власти, которым он доверяет подписывать сертификаты шифрования сервера.
Как упоминалось в другом ответе, хотя DNSSEC вполне может использоваться для начальной загрузки IPsec, это уже идеально подходит для TLS и действительно было кодифицировано в IETF как RFC6698.