В чем преимущество принудительной загрузки сайта по протоколу SSL (HTTPS)?


55

Допустим, у меня большой сайт только для контента; нет входа или выхода, нет имен пользователей, нет адресов электронной почты, нет защищенной области, ничего секретного на сайте, нада. Люди просто заходят на сайт и переходят от страницы к странице и смотрят контент.

Помимо небольшого увеличения в SEO от Google ( очень незначительного, из того, что я прочитал), есть ли какая-то польза от загрузки сайта через HTTPS?


1
Я не верю, что это дубликат принудительного использования SSL на сайте сейчас? , Хотя некоторые ответы могут оказаться схожими, этот вопрос требует совета о том, следует ли использовать SSL, а этот вопрос - нет. Во всяком случае, другой вопрос должен быть закрыт для того, чтобы быть основанным на мнении.
Стивен Остермиллер

4
Давайте рассмотрим это: в чем преимущество НЕ использовать SSL? Там нет ничего, что я знаю. О, конечно, реализация, которая была бы одноразовой и отняла бы (сравнительно со всем остальным) время. Таким образом, если у одного подхода нет недостатков и есть недостатки, у другого нет недостатков и (по вашему мнению) нет недостатков, то ... зачем придерживаться последнего?
ВЛАЗ

3
@Vld - производительность. В наши дни мы часто пытаемся оптимизировать начальное время загрузки сайта до показателей производительности менее секунды, с целью достижения 1/2 секунды. При немного медленном интернет-соединении (задержка пакетов около 100 мс) рукопожатие SSL может легко занять 300 мс, что может подтолкнуть вас к достижению цели производительности. Для мобильных пользователей это хуже: мобильные сети имеют более длительные задержки пакетов, и время обработки для проверки сертификации может легко составить еще несколько сотен мс на более медленном телефоне.
Жюль

6
Операторы мобильной связи всегда вмешиваются в незашифрованный HTTP-трафик, будь то сжатие изображений (избыточное), внедрение зловредного Javascript или более агрессивных заголовков управления кэшем. HTTPS предотвратит всю эту ерунду.
Андре Бори

2
@Josef Не правда. HTTP / 2 также работает с незашифрованными соединениями. Ни один браузер не может сделать это, но это ограничение браузера, а не HTTP / 2. Сказать, что «HTTP / 2 работает только через TLS» - все равно, что сказать, что «технология X не работает, потому что Internet Explorer ее не реализует». Посмотри, куда это нас привело.
Agent_L

Ответы:


84

HTTPS не только обеспечивает секретность (в которой вы сомневаетесь в ценности, хотя для этого все же есть веские причины), но и подлинность , которая всегда имеет ценность. Без него вредоносная точка доступа / роутер / провайдер / тд. может переписать любую часть вашего сайта, прежде чем показывать ее пользователю. Это может включать в себя:

  • внедрение рекламы для ваших конкурентов
  • вставлять рекламу или раздражающие виджеты, которые портят ваш сайт и наносят вред вашей репутации
  • Внедрение эксплойтов для загрузки вредоносных программ на компьютер посетителя, который затем (справедливо!) обвиняет вас в этом.
  • замена загрузок программного обеспечения с вашего сайта на те, которые содержат вредоносное ПО
  • снижение качества ваших изображений
  • удаление частей вашего сайта, которые они не хотят, чтобы вы видели, например, вещи, которые конкурируют с их собственными услугами или изображают их в плохом свете
  • и т.п.

Неспособность защитить ваших пользователей от этих вещей безответственна.


27
@ Майк Не совсем. Для этого существует множество готовых программ, и все они прекрасно справляются с распаковкой и повторным сжатием.
ceejayoz

3
@ Майк Не совсем. Полностью переписанный прокси-сервер может декодировать весь трафик и вводить все, что захочет, заново.
Наюки

10
К вашему сведению, большинство, если не все мои примеры действительно были замечены в дикой природе.
R ..

2
@DavidMulder ваш первый комментарий сказал « де централизация [...] не очень хорошая вещь»
jiggunjer

3
Можем ли мы не превратить комментарии к этому ответу в не по теме напыщенную речь о не связанных вопросах?
R ..

25

"ничего секретного на сайте"

... По вашему мнению . Может быть прекрасная причина, по которой кому-то нужно безопасное соединение. Это (частично) создает конфиденциальность:

Мой администратор может видеть , что я просматривающий некоторые изображения сайта на моем телефоне через URL, но он не может сказать , если я смотрю фото симпатичных кошек или хардкор порно. Я бы сказал, что это чертовски хорошая конфиденциальность. «контент» и «контент» могут изменить мир к лучшему. - Agent_L

Вы можете подумать, что это незначительно, или, может быть, это не имеет большого значения сейчас, но может быть в другой момент времени. Я твердо верю, что никто кроме меня и веб-сайта не должен точно знать, что я делаю.

Это создает доверие. Наличие замка является признаком безопасности и может свидетельствовать об определенной степени мастерства в отношении веб-сайта и, следовательно, ваших продуктов.

Это делает вас меньшей целью, например, для атак MitM. Безопасность увеличивается.

С такими инициативами, как Let's Encrypt , которые делают это намного проще и свободнее , недостатков не так много. Мощность процессора, потребляемая SSL, в наши дни ничтожна.


11
К сожалению, SSL не мешает корпоративным ИТ-специалистам, вашему интернет-провайдеру или пользователям в общественных кафе с вами узнать, какие сайты вы посещаете. Поиски DNS все еще сделаны в открытом виде . Хотя они не могут видеть ни содержимое, ни точный URL, ни то, что вы даже используете веб-браузер, они могут видеть, что вы заходите на penisland.com (который, конечно, сайт для любителей пера, но может быть неправильно истолковано). Использование VPN или SOCKS5 прокси защитит ваши DNS-запросы.
Шверн

3
@Martijn: с указанием имени сервера (которое поддерживают все современные браузеры) имя хоста веб-сайта само по себе отправляется открытым текстом как часть рукопожатия HTTPS. Дело не только в атаках через боковые каналы и не может быть смягчено, например, DNSsec.
Кевин

3
@Schwern Я никогда не понимал аргумент, что HTTPS не защищает имя хоста, потому что поиск DNS и SNI и сертификат сервера находятся в открытом виде. Конечно, это верно, как указано, но обычный текст HTTP ни в коем случае не лучше в этом отношении!
CVn

5
@Schwern Моего администратор может видеть , что я просматриваю Tumblr на моем телефоне, но он не может сказать , если я смотрю фото симпатичных кошек или хардкор порно. Я бы сказал, что это чертовски хорошая конфиденциальность. «контент» и «контент» могут изменить мир к лучшему.
Agent_L

2
@Agent_L Нет, даже это не очень хороший совет. Если вы зайдете в https://penisland.tumblr.com/свой браузер, то сделаете DNS-запрос, для penisland.tumblr.comкоторого, если вы не защитили свои DNS-запросы, администратор сети может видеть. Затем ваш браузер должен получать изображения, Javascript, CSS и рекламу из разных доменов, которые генерируют больше запросов DNS. Они могут быть из любого домена. Несколько порно Tumblr домены Я пытался не имею ничего очевидного, Tumblr , как правило, принимающие изображения и видео в доме, но вы не можете полагаться на это для обеспечения конфиденциальности.
Шверн

12

Вы получаете поддержку HTTP / 2 , новый веб-стандарт, призванный значительно повысить скорость загрузки веб-сайтов .

Поскольку производители браузеров решили поддерживать HTTP / 2 только через HTTPS, включение HTTPS (на сервере, поддерживающем HTTP / 2) - единственный способ получить это быстрое обновление.


1
Это довольно много, и его нужно раскручивать больше. Это оправдывает загрузку HTTPS только для большинства менеджеров.
Деви Морган

10

(Детали взяты из моего ответа на аналогичный вопрос.)


HTTPS может достичь двух вещей:

  • Проверка подлинности . Убедиться, что посетитель общается с реальным владельцем домена.
  • Шифрование . Убедиться, что только этот владелец домена и посетитель могут прочитать их сообщение.

Вероятно, все согласны с тем, что HTTPS должен быть обязательным при передаче секретов (например, паролей, банковских данных и т. Д.), Но даже если ваш сайт не обрабатывает такие секреты, есть несколько других случаев, когда и почему использование HTTPS может быть полезным.

Злоумышленники не могут подделать запрошенный контент.

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

  • Включение вредоносного программного обеспечения в программное обеспечение, которое вы предлагаете для загрузки (или, если вы не предлагаете загрузку программного обеспечения, злоумышленники начинают это делать).
  • Цензура некоторых ваших материалов. Изменение вашего выражения мнения.
  • Инъекционная реклама.
  • Замена данных вашей учетной записи пожертвования своими собственными.

HTTPS может предотвратить это.

Злоумышленники не могут прочитать запрошенный контент.

Используя HTTP, перехватчики могут узнать, какие страницы / контент на вашем хосте посещают ваши посетители. Хотя сам контент может быть общедоступным, знание того, что конкретный человек потребляет его, может быть проблематичным:

  • Это открывает вектор атаки для социальной инженерии .
  • Это нарушает конфиденциальность.
  • Это может привести к слежке и наказанию (вплоть до тюремного заключения, пыток, смерти).

Это, конечно, зависит от характера вашего контента, но то, что кажется вам безвредным, может быть истолковано другими сторонами иначе.

Лучше быть в безопасности, чем потом сожалеть. HTTPS может предотвратить это.


1
Действительно, HTTPS может предотвратить это. В некоторых ситуациях это не может быть. Посмотрите Lenovo Superfish для сравнительно недавнего примера.
CVn

@ MichaelKjörling: Да, я знаю об этом (именно поэтому я убедился, что использовал «can»;)), но это проблема, проистекающая из поведения посетителя, а не из-за самого HTTPS или способа использования веб-мастером это верно? Посетителю следует позаботиться о том, каким CA доверять (и посетителю следует позаботиться о том, какое программное обеспечение установить, особенно если у него есть разрешение поиграть со списком CA, которому можно доверять).
unor

На самом деле; Я не спорю с вашей точкой зрения, а только добавляю к ней!
CVn

6

Это предотвращает атаки «посредника», которые заставляют вас думать, что вы посещаете свой сайт, но представляют страницу, которая фактически принадлежит другому и может попытаться получить информацию от вас. Поскольку данные зашифрованы, злоумышленнику также становится сложнее манипулировать страницей в том виде, в каком вы ее видите.

Поскольку вам нужен сертификат SSL, который подтверждает, что вы являетесь владельцем сайта как минимум, давая хотя бы некоторую проверку того, кто вы есть.


3

Маркетинговые фирмы, такие как Hitwise, платят интернет-провайдерам за сбор данных о вашем сайте, когда вы не используете SSL. Собираются данные о вашем сайте, о которых ваши конкуренты могут не знать:

  • демография пользователя
  • статистика посещений
  • популярные страницы
  • ключевые слова поисковой системы (хотя с "не предоставлено" это менее важно в наши дни)

3

И, чтобы добавить еще одну вещь ко всем ответам, я просто расскажу о задержке. Потому что, похоже, никто не писал здесь об этом.

Низкая латентность HTTP между клиентом и сервером имеет решающее значение для создания быстро загружаемых, быстро реагирующих веб-сайтов.

Сам по себе TCP / IP имеет трехстороннее рукопожатие (для начальной настройки соединения для простого HTTP через TCP требуется 3 пакета). Когда используется SSL / TLS, настройка соединения более сложна, а это означает, что задержка для новых HTTPS-соединений неизбежно выше, чем для обычного HTTP.

Проблема с HTTP заключается в том, что это небезопасно. Поэтому, если у вас есть конфиденциальные данные, вам нужна какая-то форма безопасности. Когда вы вводите что-то в свой веб-браузер, начиная с «https», вы просите свой браузер использовать уровень шифрования для защиты трафика. Это обеспечивает разумную защиту от подслушивающих, но проблема в том, что это будет медленнее. Поскольку мы хотим зашифровать наш трафик, потребуются некоторые вычисления, которые увеличивают время. Это означает, что если вы не спроектируете свою систему правильно, ваш сайт будет выглядеть медленным для пользователей.

Заключить:

У меня большой сайт только для контента; нет входа или выхода, нет имен пользователей, нет адресов электронной почты, нет защищенной области, ничего секретного на сайте, нада. Люди просто заходят на сайт и переходят от страницы к странице и смотрят контент.

Если это так, я вообще не буду использовать SSL. Я хотел бы, чтобы при нажатии на мою страницу она открывалась за одну секунду. Это из опыта пользователя. Вы делаете, как хотите, я просто не ставлю сертификаты на все, что я делаю. В этом конкретном случае я бы не стал его использовать.


ИМО, это такой же правильный ответ, как и тот, который получает все голоса.
Майкл Ягер

youtube.com/watch?v=e6DUrH56g14 упоминает некоторые методы для снижения влияния на производительность, даже если вы (или большая часть ваших клиентов) по какой-то причине не можете использовать HTTP / 2.
CVn

1

Помимо преимуществ, упомянутых другими, есть одна причина, которая заставит вас перейти на SSL, если вы не заботитесь о своих посетителях, которые используют Chrome - новые версии Chrome (начиная с конца года, насколько я помню) для всех сайтов, которые не используют HTTPS, по умолчанию будет отображаться предупреждение (которое будет отталкивать пользователей от вашего сайта).

//РЕДАКТИРОВАТЬ:

Вот ссылки на две более подробные статьи, хотя я не могу найти ту, о которой читал, когда они планируют официально представить эту функцию:

https://motherboard.vice.com/read/google-will-soon-shame-all-websites-that-are-unencrypted-chrome-https

http://www.pandasecurity.com/mediacenter/security/websites-that-arent-using-https/


Это не идеальная цитата для утверждения, сделанного в ответе, но всегда есть маркировка HTTP как небезопасного .
CVn

1

Ответ прост : нет веской причины не делать этого . В прошлом были споры об использовании SSL только там, где это абсолютно необходимо (например, на сайтах электронной коммерции, собирающих платежные реквизиты).

В основном это было связано с процедурой установки сертификатов SSL, стоимостью, дополнительной нагрузкой на веб-сервер и ограничениями сети - в то время, когда у людей не было широкополосного доступа и т. Д. Ни одна из этих причин не применима в 2016 году.

Что касается SEO, мы знаем, что целью большинства поисковых систем является предоставление наилучших результатов для своих пользователей, и это можно сделать, предоставив им безопасное соединение с просматриваемым сайтом. В этом отношении поисковым системам все равно, есть ли на сайте «конфиденциальные» данные (либо представленные, либо собранные); Это просто тот случай, когда сайт обслуживается по HTTPS, любые потенциальные риски аутентификации и шифрования значительно минимизируются, поэтому сайт будет считаться «лучше», чем аналогичный сайт без HTTPS.

По сути, это настолько просто и понятно для реализации, что сегодня это просто лучшая практика. Как веб-разработчик, я просто рассматриваю установку SSL-сертификата, а затем принудительное выполнение всех запросов по HTTPS (очень просто с помощью .htaccess или его эквивалента) в качестве стандартной части любого сайта или веб-приложения, которое я создаю.


1

В дополнение к другим ответам браузеры должны (как в RFC 2119) отправлять User-Agentзаголовок. Он предоставляет достаточно информации о том, какую платформу использует пользователь, если он отправляет реальную User-Agent. Если Ева сможет подслушать запрос, сделанный Алисой, и Алиса отправит фактический User-Agent, то Ева будет знать, какую платформу Алиса использует, без того, чтобы Алиса не подключилась к серверу Евы. С таким знанием будет легче взломать компьютер Алисы.


Это немного похоже на то, что если Ева увидит VIN-номер автомобиля Алисы через лобовое стекло, то Еве будет легче проникнуть в машину Алисы, потому что номер VIN позволяет ей узнать, какую марку и модель автомобиля имеет Алиса. Конечно, это возможно, но есть множество способов получить практически одинаковую информацию без MITM-данных, которые едва ли регистрировались бы как нечто большее, чем фоновый шум в Интернете для конечного узла в сети. Например: Ева (или, возможно, Мэллори) может отправить Алисе по электронной почте ссылку на веб-страницу, находящуюся под их контролем. Люди любят нажимать на ссылки.
CVn

1

У вас есть два варианта защиты основного домена (mysite.com) и его поддоменов (play.mysite.com и test.mysite.com). SSL предназначен не только для электронной коммерции, сайтов продавцов платежей, где финансовые транзакции или учетные данные для входа публикуются на веб-сайте. Это так же важно для контент-сайта. Злоумышленники всегда ищут простой HTTP-сайт или лазейку на веб-сайте. SSL не только обеспечивает безопасность, но и аутентифицирует ваш сайт. Основное преимущество наличия SSL на контентном веб-сайте заключается в том, что

  • Вы можете избежать атаки «человек посередине», которая может изменить содержание сайта.

  • Кроме того, ваш веб-сайт будет иметь подлинность, которая уведомляет посетителей о том, что их информация будет защищена, если они предоставят доступ к веб-сайту.

  • Они получают гарантию подлинности сайта.

  • Кроме того, ваш веб-сайт будет свободен от внедрения вредоносной рекламы, эксплойтов, нежелательных виджетов, замены программного обеспечения и вреда веб-страниц, если у вас есть SSL на вашем веб-сайте.

  • SSL-сертификат предлагает статическую печать сайта, которая может быть размещена на любой веб-странице для гарантии, и клиенты могут нажать на печать, чтобы узнать подробности установленного SSL-сертификата.


1

Другие ответы говорили о преимуществах HTTPS. Будет ли пользователь вынужден использовать HTTPS? По двум причинам:

  • Если вы дадите пользователям возможность не использовать HTTPS, они, вероятно, не будут, тем более что большинство браузеров по умолчанию вводят http: //, а не https: // при вводе домена в адресной строке.
  • Реализуя как защищенную, так и небезопасную версию, вы увеличиваете поверхность атаки соединения. Вы даете злоумышленникам возможность выполнить атаку с понижением рейтинга, даже если вы думаете, что используете безопасную версию.
  • Если вы перенаправите каждый http: // URL на эквивалентный https: // one, это облегчит жизнь администратору сервера и поисковым системам. Никому не нужно беспокоиться о том, что http: // и https: // должны быть эквивалентными или указывать на совершенно разные вещи. Перенаправляя друг на друга, всем становится ясно, какие URL предназначены для использования.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.