Сделать полный сайт HTTPS/SSL? Какие проблемы с производительностью /SEO и лучшая практика все еще применяются в 2012 году?

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

Является ли создание всего веб-сайта в HTTPS без проблем сегодня с точки зрения лучшей практики и производительности /SEO?

ОБНОВЛЕНИЕ: Я ищу дополнительную информацию в источниках, особенно. вокруг воздействия на SEO. Bounty добавил

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

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

  • Согласовано ли рукопожатие по каждому запросу?
  • Все ли активы должны быть зашифрованы?
  • Не будут ли браузеры кэшировать контент HTTPS, включая активы?
  • Недоступны ли прозрачные прокси-серверы ниже кэширования контента HTTPS, включая активы (css, js и т.д.)?
  • Все внешние активы (пиксели отслеживания, видео и т.д.) должны иметь версию HTTPS?
  • HTTPS и gzip могут быть не счастливы вместе?
  • Обратные ссылки и органические ссылки всегда будут HTTP, так что вы будете постоянно все время, влияет ли это на SEO/производительность? Любое другое влияние SEO на изменение этого sitewide?

Там, где некоторые крупные игроки всегда запускают HTTPS, см. Always on SSL, является ли этот параметр прецедентом/лучшей практикой

Дублирующие/связанные вопросы:
Хорошая практика или плохая практика заставить весь сайт HTTPS?
Использование SSL через весь сайт
SSL на весь сайт или его часть?

ОТВЕТЫ

Ответ 1

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

Согласовано ли рукопожатие по каждому запросу?

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

Все ли активы должны быть зашифрованы?

Да, в противном случае браузер не будет считать весь сайт безопасным.

Не будут ли браузеры кэшировать контент HTTPS, включая активы?

Я так не думаю, что кеширование должно работать нормально.

Являются ли прозрачные прокси-серверы ниже по потоку, не кэшируя контент HTTPS, включая активы (css, js и т.д.), все еще проблема?

Для прокси-сервера кэшировать SSL-шифрованные соединения/активы прокси-серверу необходимо будет расшифровать соединение. Это в значительной степени отрицает преимущество SSL. Так что да, прокси не будут кэшировать контент.

Прокси-сервер может быть конечной точкой SSL для клиента и сервера, поэтому он имеет отдельные сеансы SSL с каждым и может видеть передаваемый текст. Одно соединение SSL будет между прокси-сервером и сервером, прокси-сервер и клиент будут иметь отдельное соединение SSL, подписанное с сертификатом прокси-сервера. Это требует, чтобы клиент доверял сертификату прокси-сервера и прокси-сервер доверял сертификату сервера. Это можно настроить таким образом в корпоративной среде.

Для всех внешних активов (пикселов отслеживания, видео и т.д.) должна быть версия HTTPS?

Да.

HTTPS и gzip могут быть не счастливы вместе?

На разных уровнях протоколов это должно быть хорошо. gzip согласовывается после того, как уровень SSL помещается поверх потока TCP. Для разумно хорошо управляемых серверов и клиентов проблем не должно быть.

Обратные ссылки и органические ссылки всегда будут HTTP, так что вы будете постоянно работать, влияет ли это на SEO?

Почему обратные ссылки всегда будут HTTP? Это не обязательно данное. Насколько это влияет на SEO, многое зависит от рассматриваемого SE. Интеллектуальный SE может признать, что вы просто переключаете протоколы и не наказываете за это.

Ответ 2

1- Согласовано ли рукопожатие по каждому запросу?

Здесь есть две проблемы:

  • Большинство браузеров не нуждаются в восстановлении нового соединения между запросами на один и тот же сайт, даже с простым HTTP. HTTP-соединения могут поддерживаться в живых, поэтому нет, вам не нужно закрывать соединение после каждого HTTP-запроса/ответа: вы можете повторно использовать одно соединение для нескольких запросов.

  • Вы также можете избежать выполнения нескольких рукопожатий, когда требуются параллельные или последующие соединения SSL/TLS. Существует несколько методов, описанных в ImperialViolet - оверклокинг SSL (определенно соответствующий этому вопросу), написанный инженерами Google, в частности возобновление сеанса и ложное начало, Насколько мне известно, большинство современных браузеров поддерживают хотя бы возобновление сеанса.

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

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

2- Будут ли все активы зашифрованы?

Да, как всегда. Если вы обслуживаете страницу через HTTPS, все используемые ею ресурсы (iframe, скрипты, таблицы стилей, изображения, любой запрос AJAX) должны использовать HTTPS. Это происходит главным образом потому, что нет способа показать пользователю, какой части страницы можно доверять, а какие нет.

3- Не будут ли браузеры кэшировать контент HTTPS, включая активы?

Да, они будут, вы можете либо явно использовать Cache-Control: public для обслуживания своих активов, либо предположить, что браузер сделает это. (На самом деле вам следует предотвратить кэширование для чувствительных ресурсов.)

4- Являются ли прозрачные прокси-серверы ниже по потоку, не кэшируя содержимое HTTPS, включая активы (css, js и т.д.), все еще проблема?

Прокси-сервер HTTP просто передает соединение SSL/TLS, не просматривая их. Однако некоторые CDN также предоставляют HTTPS-доступ (все ссылки на API-интерфейсы Google доступны через https://), который, кеширование браузера, обеспечивает лучшую производительность.

5. Были ли у всех внешних активов (пиксели отслеживания, видео и т.д.) версия HTTPS?

Да, это идет с точкой № 3. Тот факт, что поддерживает YouTube HTTPS-доступ.

6- HTTPS и gzip могут быть не счастливы вместе?

Они независимы. HTTPS - это HTTP через TLS, сжатие gzip происходит на уровне HTTP. Обратите внимание, что вы можете напрямую сжать соединение SSL/TLS, но это редко используется: вы можете использовать сжатие gzip на уровне HTTP, если вам нужно (там немного сжатие точки).

7- Обратные ссылки и органические ссылки всегда будут HTTP, так что вы будете постоянно все время, влияет ли это на SEO?

Я не уверен, почему эти ссылки должны использовать http://. Упрощение URL-адресов - проблема, вообще говоря, для SEO, если это то, о чем вы говорите. Я думаю, что мы увидим все больше и больше использования HTTP Strict Transport Security, поэтому больше URL https:// по умолчанию.