Где включить SSL?

Я думаю, что хорошее практическое правило - использовать SSL везде, где может быть передана конфиденциальная информация. Например: я член Wescom Credit Union. На главной странице есть раздел, который позволяет мне войти в свой счет в онлайн-банке. Следовательно, корневая страница принудительно использует SSL.

Подумайте об этом так: будет ли передаваться конфиденциальная личная информация? Если да, включите SSL. В противном случае все будет в порядке.

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

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

Браузеры также иногда имеют другую политику кеширования для HTTPS, чем для HTTP.

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

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

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

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

В нашей организации есть три классификации приложений:

• Низкое влияние на бизнес - отсутствие PII, хранение открытого текста, передача открытого текста, отсутствие ограничений доступа.
• Среднее влияние на бизнес - нетранзакционные PII, например Адрес электронной почты. хранение в открытом виде, SSL от центра обработки данных к клиенту, открытый текст в центре обработки данных, ограниченный доступ к хранилищу.
• Высокое влияние на бизнес - транзакционные данные, например SSN, кредитная карта и т. д. SSL внутри и за пределами центра обработки данных. Зашифрованное и проверенное хранилище. Проверенные приложения.

Мы используем эти критерии для определения разделения данных и определения того, какие аспекты сайта требуют SSL. Вычисление SSL выполняется либо на сервере, либо с помощью ускорителей, таких как Netscaler. По мере увеличения уровня PII возрастает сложность аудита и моделирования угроз.

Как вы понимаете, мы предпочитаем создавать приложения LBI.

Я лично придерживаюсь принципа «SSL без проблем».

Если ваш пользователь никогда не вводит номер кредитной карты, конечно, нет SSL.

Но есть неотъемлемая возможная утечка безопасности из-за воспроизведения файлов cookie.

1. Пользователь посещает сайт, и ему назначается файл cookie.
2. Пользователь просматривает сайт и добавляет данные в корзину (с помощью файлов cookie)
3. Пользователь переходит на страницу оплаты, используя куки.

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

Вы должны передавать информацию из незащищенного домена в защищенный и обратно без каких-либо гарантий защиты.

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

Если вы не можете быть уверены, что ваше программное обеспечение не подвержено этим недостаткам, я бы с самого начала предложил использовать SSL, чтобы их исходный файл cookie передавался в защищенном виде.

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

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

Я всегда делал это на всем сайте.

У полноценного сайта https есть один серьезный недостаток - это не скорость (это нормально).

Будет очень сложно запустить Youtube, ящики «Нравится» и т. д. Без предупреждения о небезопасности.

Мы уже два года работаем с полностью защищенным веб-сайтом и совершаем покупки, и это самый большой недостаток. Нам удалось заставить Youtube работать сейчас, но «Добавить это» все еще остается большой проблемой. И если они что-то изменят в протоколе, может быть, все наши фильмы на Youtube будут пустыми ...