Картинка с данными сертификата Go Daddy, TLS 1.2, AES_128, ECDHE_RSA

UPD: Первая же ветка комментариев показала, что даже на Хабре пока не все серьезно относятся к вопросу; добавил в хаб ИБ — ещё одно напоминание не будет лишним.

Комментарии (54)


  1. stp008
    23.01.2016 03:16
    -10

    А зачем это на хабре? Лишний оверхэд же


    1. iTs
      23.01.2016 04:32
      -10

      не пользы ради, а seo для


    1. zapimir
      23.01.2016 07:31
      +3

      Лишний оверхэд же

      Ну будет повод написать новость, о том, что на Хабре включили HTTP/2 :)


    1. VEG
      23.01.2016 11:56
      +57

      Чтобы всякие умники не вмешивались в трафик (например, когда wi-fi в метро вставляет свою рекламу на страницы). Было бы неплохо, если бы все со временем мигрировали на HTTPS.


      1. xenon
        23.01.2016 18:51
        -9

        Так ли уж важно это? Когда речь о безопасности, например, когда заходишь на Я.Д или просто на счет банка — тогда можно не ходить из метро, раз там небезопасный интернет. А когда речь о «просто почитать шутки на баше» — лучше читать их бесплатно в метро с рекламой, чем никак вообще (потому что за счет рекламы-то этот доступ и существует).


        1. EgorKubasov
          24.01.2016 08:06
          +6

          Рекламы и так достаточно при подключении, целых три единицы, а вот вмешиваться в сторонние сайты у mosmetro, по-моему нет права


          1. xenon
            24.01.2016 16:58

            Я в Москве в метро не был очень давно. Там при подключении — кидается какая-нибудь портянка юридического текста с которым надо согласиться? (ну или строчка вроде — начиная пользоваться интернетом — вы соглашаетесь с нашими правилами, которые можете прочитать по ссылке).

            И есть ли там альтернатива в виде обычного (GPRS, 3G итд) интернета?


            1. Envek
              24.01.2016 18:40

              Обычный мобильный интернет в метро в центре (чуть за кольцевую линию) ловит почти везде, поэтому лично я в этот распиаренный Wi-Fi — ни единым коннектом.


              1. xenon
                24.01.2016 18:58

                Тогда я даже монополии в этой ситуации не вижу. Метро дает дополнительную альтернативу на тех условиях, которые по их мнению им выгодны (на невыгодных они не стали бы давать). В этой ситуации мне кажется немного странным диктовать им, как они должны предоставлять услугу. (Главное, что они ее предоставляют честно — все минусы известны). Так же, как мы не настаиваем, чтобы в какую-то колбасу клали больше мяса. Всегда есть вариант «не нравится — не ешь». Бесплатный интернет — ведь не обязательство метрополитена.


              1. grossws
                24.01.2016 20:48

                На некоторых ветках ситуация, как минимум, у мегафона ухудшилась, когда появился этот wifi.


            1. EgorKubasov
              26.01.2016 20:15

              Оказывается зайти на страницу с условиями пользования интернетом достаточно невозможно, не находясь при этом в метро, поэтому прочитаю на днях условия, перекину их сюда.


    1. Lockal
      23.01.2016 14:45
      +23

      Процитирую свой старый коммент:

      На хабре есть замечательная страничка habrahabr.ru/ppa, через которую по открытому каналу передаются паспортные данные (включая фото), СНИЛС, ИНН, WebMoney с размером выводимых средств. Да, лично вас, как читателя, это не касается, но касается меня и многих других авторов.

      … любой крупный ресурс эксплуатирует доверие пользователей. Например, вы читаете через приложение на андроиде пост вашего любимого разработчика, в котором он даёт ссылку на apk разработанного приложения. В это время взломанный роутер или MITM заменяет все ссылки на вредоносную apk-обёртку. Как скоро вы вспомните, что все клиенты хабра на андроиде работают через HTTP с учётом того, что ни одно приложение не показывает протокол?


  1. Garrett
    23.01.2016 03:43
    +1

    Сертификат валиден с 4 Июля 2014 до 4 Октября 2016


    1. dirtyHabrBobr
      23.01.2016 09:55
      +6

      Наличие сертификата != настроенный сервер;
      не знаю, что мешало раньше, но запустили буквально на днях — раньше был редирект на http


      1. spmbt
        23.01.2016 11:38

        Да, как раз на днях из-за этого понадобилось поправить юзерскрипт, который читает страницы по Ajax (чтобы протоколы совпадали), а до этого всё было и так нормально. (Т.е они были или оба http, или оба https, строго говоря.)


      1. Pashkevich
        23.01.2016 19:32
        +1

        Это случилось 21.01.16.
        Я в этом уверен.
        Мне тоже пришлось поправлять свой проект из такого перехода.


  1. VaMpir
    23.01.2016 04:17
    +3

    А изображения с habrastorage грузятся по http.


    1. valera5505
      23.01.2016 08:01

      Habrastorage загружается по https, ссылки отдает в https и работают они тоже в https :)


      1. Sl1mShady
        23.01.2016 08:27

        Я вот такой момент поймал, до этого и не замечал, что habrastorage работает по https =)


      1. VaMpir
        23.01.2016 14:30

        Да, точно. Как выяснилось, это у меня тема в Stylish добавляла несколько картинок по http, вот в консоли сообщение об ошибке и появилось.


  1. norlin
    23.01.2016 10:29
    +4

    Осталось теперь сделать редирект с http на https.


    1. valera5505
      23.01.2016 14:31
      +2

      Сейчас почти редирект — все ссылки на http версии ведут на https страницы. Обратного же пути нет.


      1. vlivyur
        25.01.2016 15:05

        Почти

        Вернуться на главную иногда приводит к загрузке всего, кроме текстов постов (ага, меню Интересные-Лучшие есть, а дальше пусто).


    1. Maccimo
      23.01.2016 16:19
      -18

      Очень раздражает, когда нужно попасть на сайт по http, а разработчик возомнил себя д'Артаньяном и перекидывает на https.


      1. sledopit
        23.01.2016 17:36
        +11

        Но зачем?


        1. tyomitch
          23.01.2016 21:26
          +10

          Может, он из командной строки телнетом сайты читает.


          1. k0ldbl00d
            24.01.2016 00:48
            +6

            Пусть поменяет телнет на curl


            1. kingpin
              24.01.2016 03:11
              +3

              Ну, полноте, отговаривать сударя от тёплого лампового телнета! Можно ведь просто добавить stunnel!


              1. begin_end
                24.01.2016 18:52
                -3

                Вообще, у той же википедии бывало что нехватает возможности смотреть через http, но… это если сайт справочный, то может быть необходимость самых экзотичных видов доступа к нему (тот же телнет, браузеры в msdos и т.д. :)), а у хабра так сойдет.


    1. dirtyHabrBobr
      23.01.2016 16:35
      +3

      Правильнее — HSTS;
      текущие настройки разрешают только TLS, а клиенты, которые его пока не умеют, ещё существуют.

      Пара топиков по делу (комментарии там не менее полезны)


      1. kingpin
        24.01.2016 00:38
        +3

        Согласно RFC 6797 UA ДОЛЖЕН принимать политику, описанную в полях заголовка HTTP Strict-Transport-Security, только при условии, что она передаётся по защищённому соединению, установленному без ошибок, и в ней отсутствуют грамматические ошибки.

        В противном случае если ответ получен через незащищённое соединение или в полях заголовка Strict-Transport-Security содержатся ошибки, то UA ДОЛЖЕН отклонить эти поля.

        tools.ietf.org/html/rfc6797#section-8.1

        Т. е. перенаправление на HTTPS должно быть осуществлено хоть один раз, чтобы UA принял и запомнил политику для хоста в своём кэше. Руководствуясь RFC, этого перенаправления не избежать.

        Либо нужно изначально публиковать адрес хоста со схемой https.

        Но и в этом случае перенаправление всё равно нужно, поскольку UA может подключиться к хосту по незащищённому соединению — потому что в его кэше нет соответствующей политики и в адресе указана схема httpи отклонить поля заголовка STS, как уже сказано выше.


        1. kingpin
          24.01.2016 01:08

          Добавлю, почему UA ДОЛЖЕН отклонять поля заголовка STS в ответе, полученном через незащищённое соединение (со схемой http).

          tools.ietf.org/html/rfc6797#section-14.3


          1. dirtyHabrBobr
            24.01.2016 03:26

            Всё правильно про шифрование.
            Разговор выше о том, что есть поводы не принуждать клиента к шифрованию редиректами.


    1. redmanmale
      23.01.2016 23:04
      +3

      HTTPS Everywhere.


  1. iamAnton
    23.01.2016 10:30
    +13

    Go daddy? хм…


    1. yadem
      23.01.2016 12:00
      +5

      Даешь Let's Encrypt!


      1. jinxal
        23.01.2016 14:56
        +5

        Рано еще Let's Encrypt давать для коммерческих сайтов. Из беты не вышли, wildcart не выпускают, срок обновления еще не устаканили (цель — перевыпуск каждый месяц, сейчас раз в три месяца), плагин для nginx еще в альфе.


        1. symbix
          23.01.2016 15:26
          +1

          Плагины — это для самых маленьких :-) по-хорошему, это надо интегрировать в используемую систему управления конфигурацией (puppet, ansible etc). Wildcard важен только для случаев, когда число субдоменов бесконечно (скажем, субдомены вида username.domain.tld), на системы с отсутствием поддержки SNI уже можно забивать.


          1. vovansystems
            23.01.2016 21:54

            а есть уже хорошие плейбуки ансибл для этого?


            1. symbix
              23.01.2016 22:35
              +1

              Прям чтобы хороших готовых на все случаи жизни — это вряд ли, а за основу взять — https://github.com/thefinn93/ansible-letsencrypt вполне сойдет, вроде. Для паппета мы тут pgassmann/letsencrypt за основу брали.


        1. kingpin
          24.01.2016 01:39

          Есть хороший HTTP/2 веб-сервер Caddy с поддержкой HTTPS, SNI.

          Причём он включает на вашем сервере HTTPS автоматически (при соблюдении небольшого ряда требований).

          caddyserver.com/docs/automatic-https


    1. kingpin
      24.01.2016 01:01
      +1

      Кто не в теме про GoDaddy, один пример. Известный всем по инструменту nmap хакер подробно объяснял свои претензии к этой компании несколько лет тому назад.

      TL;DR GoDaddy вырубают домены безо всяких объяснений и предупреждений.

      seclists.org/nmap-announce/2007/0


  1. kafeman
    23.01.2016 14:57
    +2

    Да вроде бы уже давно. Только раньше вся графика ломалась. Из-за этого пришлось добавлять исключения в HTTPS Everywhere.


  1. achekalin
    23.01.2016 20:03

    Так https работает уже некоторое время, как правильно заметили http://habrahabr.ru/post/275539/#comment_8746141 в обсуждении от 20.01.16, вот только тогда принудительный редирект на https не работал еще.

    Официально, как я смотрю, так и не оповестили до сих пор, а редирект (без передачи заголовков HSTS) включили, если я правильно понял, в субботу. Не знаю как кому, а я в этом вижу только то, что задача не облажаться перед рекламодателями перевесила приверженность принципу «никаких изменений с пятницы и до утра вторника» :)


    1. khim
      24.01.2016 17:51

      То, что они не передают заголовки HSTS — это как раз нормально. Единожды выдав заголовок HSTS его уже не «забрать» назад. Соответственно если они только-только начали перенаправлять людей на HTTPS, то этого делать не стоит. Мало ли что: ошибка какая-нибудь обнаружится, сервера нагрузку не выдержат и т.д. и т.п.

      Вот поработает Хабр под нагрузкой неделю-другую в HTTPS режиме — можно будет уже и HSTS включить…

      Что касается времени включения… это нужно делать тогда, когда посетителей на сайте минимум… у меня доступа к статистике Хабра нет — может это и есть суббота?


      1. kingpin
        24.01.2016 19:40
        +1

        Единожды выдав заголовок HSTS его уже не «забрать» назад.

        О ла ла! Директива-та max-age вам чем не угодила?

        Хост может отправлять заведомо малую величину на период настройки. Например, две минуты. А потом не посылать заголовок HSTS, если пока решено не заставлять UA устанавливать с хостом защищённое соединение. И UA, который успел запомнить хост как HSTS-хост через пару минут об этом благополучно забудет.

        Strict-Transport-Security: max-age=240

        Либо в любое время изменить действующую политику, присвоив иное значение этой дерективе. Например, пусть теперь UA целый год будет считать хост HSTS-хостом, раз всё настроили правильно.

        Strict-Transport-Security: max-age=31536000

        Или же хост может принудить UA забыть, что он является известным HSTS-хостом, и с тех пор UA не будет сам пытаться устанавливать с хостом защищённое соединение.

        Strict-Transport-Security: max-age=0

        Т. е. хост вполне может манипулировать политикой, находящейся в кэше UA. Так того требует RFC.

        tools.ietf.org/html/rfc6797#section-6.1.1


        1. khim
          24.01.2016 20:33

          Т. е. хост вполне может манипулировать политикой, находящейся в кэше UA. Так того требует RFC.
          Именно. Но «забрать HTST заголовок назад» нельзя! А именно это и требуется «в случае чего».

          Я-то надеялся, что вы, зная такие умные слова как max-age, HSTS и прочие можете ещё и думать… но похоже этому вас не учили.

          Итак, картина маслом: вы включили перенаправление на HTTPS, добавили HSTS и… ваши сервера не выдержали нагрузки. То ли вы что-то не так настроили, то ли «энтропия кончилась», неважно.

          Ваши HTTPS-сервера лежат. Ваши дельнейшие действия? Притом, что у вас HTTP-сервера живы (они уже годы как под нагрузкой и её отлично держат). Как вы будете «отзывать» HSTS? Подсказка: вся суть HSTS в том, чтобы какое-нибудь MosMetro не могло через HTTP вас направить на другой сайт!

          Единственный вариант — изначально выдавать что-нибудь типа max-age=240, но… с практической точки зрения разницы почти нет (ну действительно — что это за защита от MiTMа на две минуты?), а с точки зрения конфигов — это лишняя стадия и лишняя возня с настройками. Смысл всего этого?

          Появится у руководства Хабра уверенность в том, что HTTPS — это «всерьёз и надолго», можно будет и HTST включить.


          1. kingpin
            24.01.2016 22:19
            +3

            Единственный вариант — изначально выдавать что-нибудь типа max-age=240, но… с практической точки зрения разницы почти нет (ну действительно — что это за защита от MiTMа на две минуты?

            Это не «защита на две минуты», я такого смысла не вкладывал. Это возможность дать UA запомнить хост как HSTS-хост и потребовать, чтобы как только UA это сделал, он в течение заданного директивой max-age времени устанавливал с хостом защищённые соединения — только так можно гарантировать, что все UA используют защищённое соединение, и посмотреть реальные цифры по нагрузке. Если что-то пойдёт не так, то через пару минут политика устареет, и UA снова сможет устанавливать незащищённое соединение с хостом.

            а с точки зрения конфигов — это лишняя стадия и лишняя возня с настройками. Смысл всего этого?

            Одна строчка в файле конфигурации веб-сервера — уже возня? Пример для nginx.

            add_header Strict-Transport-Security "max-age=120;";

            Даже перезапуска веб-сервера не требуется, чтобы изменения в конфигурационных файлах вступили в силу.

            sudo service nginx reload

            Подсказка: вся суть HSTS в том, чтобы какое-нибудь MosMetro не могло через HTTP вас направить на другой сайт!

            Не совсем так. STS позволяет защитить от целых трёх классов разных угроз: пассивные виды сетевой атаки, активные виды сетевой атаки, неидеальность веб-разработчиков.

            Перенаправление на другой сайт относится к классу активных, поскольку исходный ответ от хоста изменяется третьей стороной.

            Примеры пассивной угрозы — это прослушка трафика, кража идентификаторов сеансов, кук, session hijacking.

            И так далее. Подробности в RFC.

            tools.ietf.org/html/rfc6797#section-2.3

            P. S. Не хамите.


  1. k0ldbl00d
    24.01.2016 00:57
    +7

    Когда-то мне было всё равно как работает сайт (любой, не только habr) — с https или без. Но с некоторых пор «зеленый замочек» стал неотъемлемым символом безопасности. Я, как минимум, не хочу чтобы кто-то кроме меня и владельца веб-сервера знал к каким url я обращался, что передавал и что принимал. И дело тут не в законности моих действий, а в ощущении приватности. Ну и как выше заметили на счет рекламы, но встраиваемая реклама — еще не самая страшная беда. Мне доводилось пользоваться в одном баре открытым wi-fi, настроенным таким образом, что при открытии любой страницы в браузере почти сразу начиналась загрузка apk-приложения. Так что HTTPS я вижу столько не как средство собственной защиты, сколько знак заботы о моей приватности со стороны владельцев ресурса. Ура, Habrahabr!


    1. s5656
      24.01.2016 20:17

      Загружая хабр, вы загружаете яндекс.метрику и гугл аналитикс… все и так знают к каким URL'ам вы обращаетесь…


      1. dirtyHabrBobr
        25.01.2016 13:42

        AdBlock и NoScript могут не только лишь все.


      1. bromzh
        25.01.2016 14:46

        Ghostery есть, как раз от жучков спасает, и интерфейс удобный.


      1. vlivyur
        25.01.2016 15:09

        На это повлиять со своей стороны можно.


  1. russum
    29.01.2016 18:45

    Блин, теперь мой роутер не может заблокировать вход на хабру по url… :(