Что такое HTTP и HTTPS?

И почему использование HTTPS - это еще не означает что все данные находятся в безопасности?
***ВНИМАНИЕ! Данный текстовой документ, далее: "Статья" является произведением корпорации Andromeda Cloud, inc и находится под защитой авторских прав! Ни одна в мире компания, частное лицо, ИП, физическое, или юр. лицо, а так-же организации, и правительства, включая новостные сайты, а так-же сайты партнеров, в том числе и стратегических, НЕ имеют право на копирование статьи, его содержимого, а так-же цитировать статью, размещать, перепечатать, запустить в газетах, или на любых порталах, либо на любых ресурсах в сети интернет и за его пределами, без ссылки на корпорацию Andromeda Cloud, inc, указывая корпорацию Andromeda Cloud, inc как автора данной статьи. Любое прямое, и/или частичное нарушение данного правила, приведет к собственному расследованию со стороны Федеральной службы безопасности Корпорации Андромеда. Благодарим за Ваше понимание.***
Корпорация Andromeda Cloud, inc провела тестовой опрос у 1000 владельцев ВЕБ-сайтов и сейчас поделимся результатами.
О HTTP(S) протоколах.
Протокол HTTP обычные пользователи могут заметить во время посещения веб-сайтов в сети "интернет", со своего компьютера, или мобильного телефона, либо встретить на обычных сайтах, на форумах, заметив какую-либо ссылку, которая начинается с "http://" многие не задаются вопросом, что это такое? Почему некоторые ссылки начинаются с http://, а некоторые с httpS?
HTTP - это "Hypertext Transport Protocol" - протокол транспортирования гипертекста. Почему гипертекста спрашиваете Вы? Во первых, нужно узнать что такое сам гипертекст: Гипертекст, это ряд документов, содержащих текстовую, аудио и/или видеоинформацию, связанных между собой взаимными ссылками в единый текст. Вы все верно читали. Аудио и Видео текст, а еще и текст изображений, красивых эффектов сайта и много чего другого. Все что мы видим в браузере, да и вообще в компьютере, - это ряд большого количества текстовой информации, собранный в правильных форматах. Они очень идеальны, и состоят из идеально правильно написанного машиной кода. Да-да. Именно машинный код может генерировать идеальную кодировку видеозаписей, аудио-сигналов, или картинок. Любые человеческие пальцы замешанные в кодировку любого файла, за исключением обычных текстовых документов, или файлов написанные на обычных языках программирования, например "PHP" - Могут привести к поломке файла без возможности восстановления. Потому и были созданы такие графические редакторы, которые посчитают и выполняют миллионы кодировок ежеминутно, что и избавляет человеческим пальцам от обязанности вручную внедрить все правки в кодировку например изображения, или в видео.
С гипертекстом разобрались. Теперь нужно узнать о протоколе, который защищает передачу самого гипертекста с сервера к клиенту, а с клиента к серверу. (Обычными словами, - с сайта к браузеру, а с браузера к сайту).
Мы поговорим о внедрении HTTPS протокола. Это тот-же HTTP, но в конце с буквой S. Это название протокола расшифруется как Hypertext Transport Protocol SECURE. (Безопасный протокол транспортирования гипертекста).
HTTPS - это расширение протокола HTTP, но с поддержкой шифрования в целях повышения безопасности передаваемых данных. Данные в протоколе HTTPS передаются поверх криптографических протоколов SSL или TLS. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.
Протокол HTTPS довольно старый. Он был разработан компанией "Netscape Communications" для браузера Netscape Navigator в 1994 году. На данный момент по 16.09.2018 г. - получается, что протоколу HTTPS почти 25 лет.
Несмотря на активное развитие интернета, спустя почти 25 лет, протокол HTTPS является актуальным и самим предпочтительным для администраторов серьезно относящихся к безопасности своих веб-сайтов. Но все изменилось в 2016-ом году, когда Google объявил о том, что в поисковой выдаче своего сервиса (Google Search) - будет больше придавать значения к сайтам с поддержкой использования HTTPS. Это стал отличным маркетинговым шагом для Google, inc и для его партнеров. - CA (Certification Authority), или-же на русском - ЦС (Центры Сертификации). Каждый центр сертификации проходит тщательную проверку и имеет достаточную лояльность у разработчиков программного обеспечения популярных ОС, производителей железа и у интернет гигантов. Google, Microsoft, APPLE. Каждый... Каждый из них берет значительную сумму денег у центров сертификации, для внедрения этих сертификатов в наши устройства. Да! И мы с этим соглашаемся, что мы будем доверять списку CA сертификатов в Windows при установке ОС на компьютер, или покупая Iphone, или Android устройство. Ну а кто читает политику конфиденциальности и правила пользования? - правильно, почти никто! А гиганты, на этом зарабатывают миллиарды. Вы даете автоматическое согласие этим компаниям, что полностью доверяете им список доверенных центров сертификации, тем-самим предоставляя им возможность управлять безопасностью передаваемых Вами данных в интернет, посредством отправки данных через "Доверенных" цепочек этих сертификатов. Конечно, внедрение повышения рейтингов сайта в поисковой выдаче имело и свои плюсы. Например, многие сайты перешли к использованию HTTPS протокола, многие центры сертификации хорошо на этом заработали и зарабатывают, появились все новые и новые Центры сертификации и новые партнеры для этих гигантов. Интернет безопасность увеличилась на 25%! За этим шагом и начали следовать другие поисковые системы: MSN, YANDEX, MAILRU, BING. Да! Это привело к более повышению интересов администраторов к HTTPS и к платным SSL сертификатам. Во благо человечества, запустились и бесплатные SSL сертификаты, но они скорее-всего ухудшали жизни администраторов. Все дело в их сроке годности - НЕ более чем 3 месяца. Но обычно - 1 месяц. Это заставляло администратору в каждый раз пройти проверку и переустановку сертификата на сайт, что очень надоедало, и являлась отличной мотивацией для того, чтобы администратор перешел к платному варианту. К счастью, был один отличный вариант. Это на тот момент Шведская компания, а на данный момент Китайская, предлагала бесплатное решение - SSL сертификат на год бесплатно. А компания WoSign - китайский центр сертификации, предлагала SSL сертификаты бесплатно аж на три года и до 100 доменов включительно! Это была подарком судьбы для всего человечества сисадминов. Но человеческие пальцы дошли и до них. Эти компании были мишенью номер один для всех коммерческих центров сертификации, таких как Comodo, Thawte, Symantec, SSLCOM, RapidSSL, а так-же их партнеров, таких как Google, Microsoft и другие. Все дело в том, что пользователи предпочли экономить тысяча долларов на сертификаты, а это мешало этим "ЦС" зарабатывать эти-же доллары. Они искали компромиссы и нашли. Из-за пару пустяков, STARTCOM и WoSign получили блокировку на год. Сначала у Mozilla, потом у Google. Это стал шоком для всех любителей бесплатных SSL. Это был тестом и все прошло успешно. Заметив о выросте продаж платных SSL, эти компании принялись сменить годовую блокировку на бесконечную блокировку без объяснений причин. Это поставило конец компании STARTCOM, а WoSign превратился в никому не нужную площадку, который до с их пор пытается восстановить свой статус центра сертификации. Все сработало отлично! Гиганты стали зарабатывать еще больше и все больше ограничивая свободу в интернете, а так-же ограничивая безопасность в сети. В отличии от многих ЦС, WoSign потребовала CSR (Certificate Signing Request) что потребовало генерацию приватного ключа в машине клиента, а сам сертификат генерировался на сервере ЦС, но у них не был доступ к самому ключу расшифровки сертификата. Сторонние ЦС действуют не так. Они генерируют ключи на своих серверах и сохраняют их так-же на серверах. Администраторы бегают за рейтинги в Google, Yandex, Bing переходя на HTTPS протокол, но НЕ зная как правильно защищаться от хакеров и чужих человеческих пальцев. Появились в сети все больше веб сайтов для генерации CSR, почти все ЦС сегодня предлагают 2048 битное решение, все предлагают генерацию ключа на сервере во благо пользователя, в целях сохранении времени пользователя. БОЛЕЕ того! - Они отправляют эти ключи пользователю на E-Mail, предоставляя хакерам более быструю возможность получения доступа к этим файлам, а так-же не забываем о спец. службах, и о человеческих пальцев администраторов этих майловых служб. Это делает веб сайт с красивым зеленным значком, уверяющим пользователей, что сайт безопасный. И все! Больше администраторам ничего не интересно. Но к этому безопасному сайту имеют доступ: Центр Сертификации. Посредник центра сертификации. Реселлер ЦС. Администраторы реселлеров, посредников и самого ЦС, Далее файлы на хостинге сервера, у администраторов хостинга, на мейле администратора домена, что и значит что и у спец. служб при необходимости, а так-же и у администраторов этого майлового сервера. Обычно Gmail, Yahoo, Outlook, mailRU, Yandex. Учитывая миллионы взломов и подборок майловых паролей и базы данных в руках хакеров с миллионами пользователями тех и иных майловых ресурсов, - неудивительно, что эти ключи попадаются и хакерам.
Но на этом НЕ зацикливаемся и продолжаем идти вперед. Google решил снять с рунета сам протокол HTTP. Дело благое, все больше будут пользователей защищенного протокола, но вопрос тут в том, во благо кого? - а ответ и так уж и понятен. SSL - это громкий бизнес и всем неоднозначно все-ровно как все сертификаты выдаются. Пока, эти, или иные компании не набьют по карманам этих гигантов, считающих себя "владикой" сети, или "интернета". Это так и есть! Пока мы все используем их программные обеспечения и продукты, мы их должники. Несмотря на то, что мы ПЛАТИМ им за те, или иные ПО, или преимущества. .Google, Microsoft, Comodo и многие из этих явно заинтересованных в такой цензуре в сети интернет компании - являются крупными партнерами компании Andromeda Cloud, inc. Но мы - свободная корпорация и нам не страшно сказать это им в лицо напрямую. Поэтому, многие из них называют нас "партнерами", чисто из-за осторожности к нам.
Сам HTTPS протокол безопасен. Но его использование не гарантирует 100% защиту информации. Сегодня, мы познакомим Вас с пунктами, которые нужно удерживать, чтобы получить 100% защищенный ресурс.
Это не реклама услуг корпорации Andromeda Cloud, inc. Все требования выполнимы и без сайтов нашей корпорации.
1). Используем выделенный сервер для веб сайта! Никаких дешевых хостингов, или премиум предложений! Нужен приватный сервер! Так-же подойдет и VPS/VDS.
2). При заказе SSL сертификата обращаем внимание НЕ на цену, а на самого центра сертификации и используемого ими сертификата подписи. Например центр сертификации "Братья близнецы из соседского гаража" продают сертификат на год за 15$, а компания Comodo продает за 100$ в год. В браузере, обе сертификаты зеленные, и проблем чисто визуальных нет.
Но проверив CA корень сертификата, мы увидим, что Братья близнецы используют механизм SHA1 + 1024 bit, а вот Comodo CA - 2048 Bit sha 256.
Значит, выбирать нужно COMODO.
3). НЕ ИСПОЛЬЗУЕМ онлайн сервисы для генерации CSR запросов выдачи сертификата. Его генерируем на своем сервере.
4). Используем длину ключа 4096bit, или выше! Сегодня, все сайты на 2048 bit, и это защищенный стандарт. Но а завтра? Кто знает? Сегодня, военные сайты и платежные системы уже используют 4096> ключи.
5) Используем SHA384 или SHA512. Это наинадежные алгоритмы хэширования ключа сертификата и самый безопасный стандарт.
6). Используем механизм валидации домена по DNS валидации. Никаких ЭМАЙЛОВ.
7). Сообщаем центре сертификации ТОЛЬКО CSR. Если сайт требует использовать их ключ, откажитесь от сертификата и потребуйте средства назад. При любом заказе, в течении 30 дней после выпуска сертификата, ЦС возвращает средства за сертификат, если пользователь потребует REFUND (Возврат) средств.
8). НЕ передаем ключ к сертификату никому. Используем его только на сервере. Не сохраняем его на разных облаках, таких как Google Drive, либо Яндекс.Диск. ЭТО НЕБЕЗОПАСНО. Не храним ключ так-же в своем Windows компьютере, или на флешке. Нужно ключ оставить только на сервере, где мы его и генерировали.
9). Используем безопасный протокол рукопожатия Diffie Hellman!
Протокол рукопожатия, это половина дела! Если она ненадежна, то хоть Ваш сертификат будет на миллион бит, - его перехват и расшифровка потребует несколько часов от хакера, а может и поменьше!
Используйте минимум 4096 Бит Диффи Хелман протокол. Старый, добрый протокол DH, был основан еще во время второй мировой войны, дабы защищать разговоры спец. служб от перехвата. И она актуальна до с их пор! (Конечно с куча обновлениями и улучшениями).
10). Используем переадресацию HTTP запросов на HTTPS. Подключить HTTPS и при этом не отказаться от HTTP, это почти одно и тоже, что лить воду в ведро без дна!
11). Используем протокол защиты от Main In The Middle (Защита от посредника) - HSTS (Http Strict Transport Security) - механизм, принудительно активирующий защищённое соединение через протокол HTTPS. Хакеры могут перехватить ваш трафик, и заставить пользователям использовать незащищенный HTTP протокол, чтобы расшифровать данные. При подключении HSTS протокола на веб-сервере, даже если Ваш сайт принимает HTTP соединения, браузер все-ровно будет обращаться к серверу по HTTPS.
12). Используем протокол HPKP. (Http Public Key Pinnging) - чтобы защищаться от возможной подмены сертификата на стороне клиента. Этот протокол отправляет пин код сертификата (Хэш) по заголовкам сервера клиенту, а браузер сравняет хэш сертификата с сертификатом представленным сервером. В случае, если сертификат подлинный, все работает, а если есть подмена, вызванный хакером, злым админом сети, или недобросовестным провайдером интернета, - то сайт не откроется из-за несоответствия пин кодов.
13). Используйте защищенный протокол шифрования TLS! Протокол SSL устаревший и уязвимый. Ему замена пришла TLS. Используем самые свежие версии протокола - TLS1.2 и TLS1.3. Можно так-же использовать TLS1.1. Не исключается TLS1.0 (Но она крайне не рекомендуется, так-как слишком устаревшая и требует патчи для повышения безопасности).
14). Используем OCSP Stapling (Online Certificate Status Protocol) - протокол проверки статуса сертификата. При активном соединении с сервером, браузер обязуется проверить статус сертификата у Центра Сертификации. Не отозвано ли оно Вами? - Это делается в случае, если у Вас украли ключ сертификата, вы перевыпустили сертификат у Центра Сертификации, но нужно-же как-то отозвать старый, уже небезопасный сертификат? А как-же заставить браузерам клиента проверить достоверность сертификата повторно? - Используем протокол OCSP Stapling, чтобы решить эту проблему.
15). Следим за версией OpenSSL на сервере. Она должна быть актуальная, чтобы не подвергалась к атакам типа HeartBleed, или чтению из памяти сервера, или его процессора. Актуальная версия OpenSSL гарантирует защищенность сервера, а так-же производительность HTTPS соединения.
16). Используем защищенные шифры для соединения с браузером клиента.
Шифры например из устаревших: DC, RC4 SHA256. SHA1 DS, MD, MD5 и другие. Шифры из защищенных: AES128GSM. AES256GSM. А самый быстрый, новый и надежный - Chacha20 poly1305 - совместимый с Quck и TLS1.3.
17). Используем механизм защиты от фрейминга Вашего сайта. Многие онлайн прокси "Браузеры" дабы позволяя пользователям сменив IP посмотреть веб-сайт, на самом деле дешифруют веб сайт, и повторно зашифровав отображают на браузере клиента. При вводе логинов и паролей, эти данные легко могут быть перехвачены. Для этого запрещаем Фрейм на сайт путем X FRAME OPTIONS заголовка на сервере.
18). Используем протокол HTTP/2 - это новый протокол версии HTTP, позволяющий передать данные одним TCP соединением к клиенту, вместо многих новых TCP соединений для каждого файла сайта, будь это картинка, музыка, файлы стилей, или сама HTML страница.
HTTP2 не только ускоряет сайт, но так-же делает его более безопасным, благодаря его нововведениям и свежим стандартам защитных механизмов.
19). Используем веб сервер NGINX. Либо связка NGINX+APACHE. Это отличный сервер, с поддержкой всех вышеуказанных алгоритмов и протоколов. А так-же, NGINX - самый быстрый веб-сервер на свете.
20). Используем CSP протокол (Content Security Policy) и протокол защиты от XSS Атак. Чтобы защищаться от опасных скриптов, загружавших на ваш сайт, посредством разных плагинов, которые могут изменить вид Вашего сайта в том числе, загружая в браузер клиента небезопасные, а чаще всего и критически опасные скрипты. Такие как рекламные материалы, назойливая реклама, либо более опасные, подмена формы авторизации, например.
HTTP Заголовки CSP и X-XSS Protection, обязательно помогут с защитой Вашего сервера.
И наконец, результаты теста:
При предложении предоставить владельцам сайтов платный SSL сертификат бесплатно, в качестве подарка, своим ключом, 90% владельцев сайтов сразу бросились получить его, не думая, что этот человек может быть хакером, и после выдачи сертификата, использовать его для расшифровки трафика сайта.
5% Воздержались от предложения.
5% Боялись пройти верификацию доменной имени.
Выводы таковы: Использование HTTPS, а так-же администраторы знающие полную политику безопасности этого протокола, ровны к нулю и не гарантируют хотя бы 70% вероятность, что данные не могут быть перехвачены сторонними людьми.
В интернете существуют лишь 107 сайтов, полностью поддерживающих все вышеуказанные политики безопасности для криптографии, из них 97 поддерживаются системой безопасности нашей корпорации. Это ровно к 0% из 100% миллионов сайтов, поддерживающих защищенный протокол HTTPS.
Мы, как корпорация по сфере информационной безопасности, гордо заявляем, что для нашей большой команды, все 100% сайтов в мире, в том числе и такие гиганты как Google, Yandex, Twitter, - уязвимы. И пока-что в ближайшем перспективе не видно, что эти сайты достигнут идеальной вершины кибер-безопасности. Нынешнее состояние интернета на уровне большой опасности.
Давайте сделаем интернет безопасным вместе с Andromeda! :)
С уважением, Andromeda Cloud, inc.