Так у TLSA только один сценарий использования: чтобы проверить соответствие сертификата на сервере по DNS-записи. Сделать это можно, например, так:
openssl s_client -connect good.dane.verisignlabs.com:443 </dev/null 2>/dev/null | openssl x509 > cert.pem
TLSSIGN=`openssl x509 -noout -in cert.pem -fingerprint -sha256 | cut -d= -f2 | tr -d :`
# 8.8.8.8 срежет ответ при расхождении подписей DNSSEC
DNSSIGN=`dig +short tlsa _443._tcp.good.dane.verisignlabs.com @8.8.8.8 | awk '{print $4 $5}'`
if [ $TLSSIGN == $DNSSIGN ]; then
echo "Invalid certificate"
# далее используем альтернативный канал
fi
В идеале должен быть не 8.8.8.8, а более надёжный канал, например, DNSCrypt.
Для Firefox есть расширение для проверки DANE, но сайтов c DANE очень мало. Зато DANE стандартизирован и его можно использовать в любых протоколах с TLS, что делают IRC-клиент Irssi и почтовый агент Postfix.
Для secondary-only почти всегда AXFR импортирует всё, что видит, т. е. можно не перечислять поддерживаемые типы записей. Хотя могут и резать.
В частности, для rollernet.us и puck.nether.net могу добавить, что они поддерживают импорт
DNSSEC (записи RRSIG и NSEC) и DANE (записи TLSA или TYPE65468).
Ну а лучший primary для работы с DNSSEC — свой primary, т. к. переподписывать записи придётся часто (пусть даже медленный; а на что ещё кэши dns-resolver-ов?).
В чём здесь биткойн хуже других валют? Особенно с учётом роста госдолга и постоянно сдвигаемого дефолта в США. Государственные деньги постоянно теряют в цене и могут быть в любой момент перевыпущены или деноминированы по желанию левой пятки президента. С таким же успехом можно купить скоропортящейся еды, чтобы через две недели попытаться обменять еду назад на деньги.
Не хватает возможности посмотреть/отфильтровать по компании, чьи услуги реселлятся. У вас ведь база данных набита в основном реселлерами, которые в глаза не видели продаваемые ими машины, а при отказе сервера могут разве что уведомить клиентов. А фильтрация могла бы пригодиться, например, чтобы найти реселлера не просто в Германии, а от Hetzner (по известности). Или не просто в Нидерландах, а от Ecatel (по защите от DDOS-аттак и роскомтеррора). Заодно это избавит от необходимости перечитывать соглашения о запретах: если реселлится Hetzner, то это как минимум означает запрет на мониторинг сетей и инструменты файлообмена у всех реселлеров.
Если проверяющие сразу открывают анонимайзеры, чтобы выполнить план по нарушениям, следующим логическим шагом проверяющих после блокировки анонимайзеров будет прописывание прокси. Раньше сайтов-анонимайзеров практически не было (а те, которые были, страшно глючили на замене гиперссылок и элементов страниц), а прокси-серверы были вполне рабочим средством доступа к сайтам. Гиковского в этом нет абсолютно ничего. Если вы на хабре рекомендуете всем заворачивать порты (и не только вы рекомендуете, кстати), то готовьтесь, что по первому запросу в яндексе «как обойти блокировку вконтакте» будет именно socks.
А сброс профиля при логине должен стать нормой для школ даже не из-за проверок, а потому что половина времени тратится на выяснение, куда делся ярлык softwarename, почему в softwarename все панели поехали, кто что посещал, кто это там забыл разлогиниться и т. д.
Поднять SOCKS-прокси на 80-м порту (или ещё проще — найти рабочий на списке анонимных прокси-серверов) -> можно ходить куда угодно. Всего лишь один шаг в сторону от сайтов-анонимайзеров.
И вообще DNS-трафик не обязан ходить по 53 порту и выглядеть как DNS. DNSCrypt, например, успешно мимикрирует под TLS/TCP и TLS/UDP.
Пруф поломался, остался кэш, в прочем это уже не важно. SSLLabs уже несколько месяцев поддерживает SNI. Проблема в кривой настройке гугла и немного в интерфейсе SSLLabs: по общей таблице видно, что SSLLabs заодно проверяют поддомен www. у всех проверяемых доменов, а этот ip возвращает сертификат только для *.google.com, что не соответствует домену четвёртого уровня www.apis.google.com.
Проблема с кэшем решается сбросом перемещаемого профиля при загрузке или правильной расстановкой прав. Это не дело, когда на общедоступном компьютере каждый новый пользователь может ознакомиться с полной историей всех запросов (а подчас и с паролями из автосохранения). А там и до пунто-свитчеров в режиме кейлоггеров недалеко. Для хранения данных между сеансами вполне достаточно отдельного раздела; если очень не хватает нужного софта, а админа нет — то туда же юзеры ставят нормальный портабельный софт, а не засирают автозагрузку и браузеры всякими барами и прочими малварями.
Может быть, но это так же означает, что кто-то другой может не донастроить, получать жалобы от пользователей и не мочь воспроизвести.
Классика: 12.7% (по данным свежего скана) всех действительных SSL-цепочек не включают сертификат промежуточного удостоверяющего центра, в итоге у владельцев сайта всё будет нормально (поскольку они закэшировали недостающий ключ в момент подписи или у другого сайта), а у случайных пользователей (особенно со свежеустановленным браузером) будут проблемы (не ssl_error_bad_cert_domain, это просто пример кривой настройки, встречаемой повсюду).
Ситуация с арифметическими преобразованиями давно описана во многих стандартах по безопасности, например, здесь. Предположить, что компилятор имеет ошибки в приоритете операций, может разве что Джефф Дин. Для всех остальных система приоритета, создаваемая генераторами парсеров, либо верна на 100%, либо не работает вообще.
Смотреть ассемблерный код в GCC стоит только в случае, если нужно изучить поведение именно на конкретном процессоре с конкретным набором инструкций. В отличие от проприетарных компиляторов, у GCC есть несколько десятков вариантов дампа в разных стадиях оптимизации: до удаления мёртвого кода, до свёртки констант, во внутреннем представлении GIMPLE и т. д. В данном случае, если скомпилировать с флагами -O0 -fdump-tree-optimized, то будет следующий вывод:
Касательно примера с float, все обобщения про C89-компиляторы и SSE — ваши личные измышления, не имеющие ничего общего с действительностью. В отсутствии требования на соответствие C89 стандарту IEEE 754 создатели GCC избрали стратегию свёртки констант с наибольшим соответствием текущей архитектуре. Для x86 это означает соответствие IEEE 754 на CPU, но не x87 FPU. Ещё раз: это выбор именно разработчиков GCC, причём конкретные усилия по соответствию IEEE 754 начали предприниматься только с четвёртой версии. В GCC 3.x свёртка констант работала в прямом смысле, как посчитает процессор, на котором работает GCC (независимо от целевой платформы). Другие C89-компиляторы могут иметь стратегию свёртки констант без потери точности или как GCC 3.x.
Прекрасный повод для Tampermonkey перехватить на себя новых пользователей. Будет один большой userscripts.org со скриптами, работающими во всех браузерах, и никому не нужный Google Web Store с кучей проплаченной адвари.
Интересен был бы эксперимент с компиляцией всего мира с AVX(2)-инструкциями для ускорения криптографии и мультимедии. Переходы между инструкциями SSE и AVX значительно замедляют программы с AVX-инструкциями. А если дистрибутив использует поголовно только SSE-библиотеки, то попытка самостоятельно скомпилировать отдельную программу с инструкциями AVX может даже замедлить программу.
В идеале должен быть не 8.8.8.8, а более надёжный канал, например, DNSCrypt.
Для Firefox есть расширение для проверки DANE, но сайтов c DANE очень мало. Зато DANE стандартизирован и его можно использовать в любых протоколах с TLS, что делают IRC-клиент Irssi и почтовый агент Postfix.
В частности, для rollernet.us и puck.nether.net могу добавить, что они поддерживают импорт
DNSSEC (записи RRSIG и NSEC) и DANE (записи TLSA или TYPE65468).
Ну а лучший primary для работы с DNSSEC — свой primary, т. к. переподписывать записи придётся часто (пусть даже медленный; а на что ещё кэши dns-resolver-ов?).
А что мелочиться? Даёшь jQuery на каждый однострочник! Поразите всех мощью селекторов!
А сброс профиля при логине должен стать нормой для школ даже не из-за проверок, а потому что половина времени тратится на выяснение, куда делся ярлык softwarename, почему в softwarename все панели поехали, кто что посещал, кто это там забыл разлогиниться и т. д.
И вообще DNS-трафик не обязан ходить по 53 порту и выглядеть как DNS. DNSCrypt, например, успешно мимикрирует под TLS/TCP и TLS/UDP.
Классика: 12.7% (по данным свежего скана) всех действительных SSL-цепочек не включают сертификат промежуточного удостоверяющего центра, в итоге у владельцев сайта всё будет нормально (поскольку они закэшировали недостающий ключ в момент подписи или у другого сайта), а у случайных пользователей (особенно со свежеустановленным браузером) будут проблемы (не ssl_error_bad_cert_domain, это просто пример кривой настройки, встречаемой повсюду).
Смотреть ассемблерный код в GCC стоит только в случае, если нужно изучить поведение именно на конкретном процессоре с конкретным набором инструкций. В отличие от проприетарных компиляторов, у GCC есть несколько десятков вариантов дампа в разных стадиях оптимизации: до удаления мёртвого кода, до свёртки констант, во внутреннем представлении GIMPLE и т. д. В данном случае, если скомпилировать с флагами
-O0 -fdump-tree-optimized, то будет следующий вывод:Касательно примера с float, все обобщения про C89-компиляторы и SSE — ваши личные измышления, не имеющие ничего общего с действительностью. В отсутствии требования на соответствие C89 стандарту IEEE 754 создатели GCC избрали стратегию свёртки констант с наибольшим соответствием текущей архитектуре. Для x86 это означает соответствие IEEE 754 на CPU, но не x87 FPU. Ещё раз: это выбор именно разработчиков GCC, причём конкретные усилия по соответствию IEEE 754 начали предприниматься только с четвёртой версии. В GCC 3.x свёртка констант работала в прямом смысле, как посчитает процессор, на котором работает GCC (независимо от целевой платформы). Другие C89-компиляторы могут иметь стратегию свёртки констант без потери точности или как GCC 3.x.
Давайте уж сразу оператор
:=, чтобы C++-ники совсем от стыда сгорели…ru.wikipedia.org/wiki/Wikia_Search, прожил полтора года.
Тоже не новая история, habrahabr.ru/post/124538/
А вывод пусть все сделают сами :)