StartSSL раздает валидные годовые SSL-сертификаты бесплатно. Другие компании берут за это деньги начиная примерно от $20 в год. StartSSL зарабатывает на сертификатах более высоких классов, включая сертификат с расширенной валидацией, а базовый сертификат делает бесплатно. Их идея заключается в том, что они не берут деньги за сервис, в котором не используется труд людей (базовая валидация домена производится автоматически).

1. О системе StartSSL и их сертификатах

Особенность функционирования сайта StartSSL заключается в том, что авторизация в панель управления производится через клиентский S/MIME сертификат. Это большая редкость в наши дни. Отсюда возникает непонимание процесса неподготовленными пользователями и тупняк на этапе освоения сервиса.

Суть заключается в том, что вместо логина и пароля вам выдается сертификат. Почти такой же сертификат, какой выдается для подтверждения подлинности сервера. Этот сертификат отправляет на сервер ваш браузер при авторизации (автоматически после вашего подтверждения). Браузер берет его из хранилища, куда сертификат должен быть импортирован до проведения авторизации. Если сертификата в хранилище не окажется, то при авторизации вы увидите браузерное сообщение об ошибке, на подобии «Не удаётся завершить защищённую транзакцию».

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

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

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

Кроме того, на домене должна работать почта. На один из ящиков из фиксированного списка (webmaster@домен, postmaster@домен, hostmaster@домен или адреса, указанные в Whois) придет письмо с кодом проверки.

2. Регистрация

Зайдите на сайт StarSSL и начните регистрацию (кликаем Sign-up). При этом нельзя использовать Google Chrome (можно Opera, Firefox, IE).

2.1. Заполните форму. Укажите свои реальные данные. Во-первых, этого требует соглашение, с которым вы соглашаетесь при регистрации. Во-вторых, эти данные проверяются вручную. В-третьих, указывать здесь фейковый данные смысла мало, т.к. кроме самого StartSSL их никто не увидит.

2.2. Укажите код подтверждения e-mail-а. Как правило, письмо с кодом приходит сразу или в течение минуты.

2.3. Дождитесь проверки указанных данных персоналом StartSSL. Да, они проверят то, что вы ввели в форме. Вручную. Если их ничего не смутит (а как правило ничего не смущает в реальных данных), вам придет ответ на e-mail, в котором будет указана ссылка на вторую активацию аккаунта (с кодом). Обратите внимание, что ссылка действует только в течение 24 часов.

Они могут задать дополнительные вопросы по e-mail для уточнения регистрационных данных. Отвечать на них имеет смысл, и опять-таки — честно.

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

Для генерации ключа выбираем 2048 бит (в выпадающем меню), так как меньшую битность StartSSL не поддерживает, а в большей едва ли есть смысл.

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

Устанавливаем обязательно.

2.4. На данный момент картина следующая: у вас есть подтвержденная учетная запись StartSSL и персональный сертификат, установленный в браузер, который заменяет для вас одновременно логин и пароль.

Этот сертификат необходимо «достать» из браузера и сохранить в надежном месте. В случае потери установленного сертификата (например, переустановка ОС или браузера) вы сможете его вновь импортировать. Кроме того, сертификат нужен для того, чтобы войти в панель с другого компьютера.

Конкретные действия для экспорта сертификата зависят от вашего браузера. Общее лишь то, что вы должны попасть в управление хранилищем сертификатов, найти там свой персональный сертификат StartSSL и экспортировать его в файл. В Opera это делается так:

Формат экспорта — с секретным ключем PKCS#12. Если такого формата нет и вы не знаете, какой формат экспорта лучше выбрать (при условии, что их несколько), экспортируйте во все :). Если вы экспортируете сертификат без ключа, смысла в этом не будет — он не будет работать.

Если вы потеряете сертификат, утратите доступ к панели. Это значит, что для получения новых сертификатов и продления старых (через выписку нового), необходимо будет заново регистрироваться.

3. Итак, ваша учетная запись подтверждена и у вас есть персональный сертификат для авторизации в панели StartSSL. Теперь самое время зайти в панель. Нажимаем на кнопку с ключами и попадаем на страницу авторизации (смотрите на первом изображении в статье). Нажимаем «Authenticate». Подтверждаем передачу серверу нашего персонального сертификата. Авторизация пройдена — вы в панели.

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

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

Панель StartSSL состоит из 3-х разделов (вкладки на изображении выше):

• Tool Box — инструментарий. Большая его часть бесполезна. Можно отметить только разделы для получения корневых и промежуточных сертификатов StartSSL и получения ранее созданных сертификатов.
• Certificates Wizard — мастер создания нового сертификата. С него начинается заказ нового сертификата для сайта или персонального сертификата. Для создания сертификата должен быть заранее подтвержден домен или адрес e-mail соответственно.
• Validations Wizard — это как раз и есть мастер проверки сайта и e-mail (а кроме того платных проверок личности и организации). С него нужно начинать получение сертификата для сайта. Каждая проверка действует 30 дней, так что при «продлении» сертификатов проверки необходимо повторять.

Итак, начинаем процесс получения сертификата для сайта.

3.1. Проверка (валидация) домена. Переходим в Validations Wizard, выбираем проверку домена (Domain Name Validation):

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

3.2. После проверки принадлежности домена нужно заказать для него сертификат. Для этого перейдите в Certificates Wizard, выберите Web Server SSL/TSL Certificate. Далее выберите из списка один из предварительно проверенных доменов.

На следующем шаге есть два варианта:

• пропустить шаг и предоставить собственноручно сгенерированный CSR со своим приватным ключем,
• или заполнить форму и сгенерировать приватный ключ в браузере.

Первый вариант выбирают те, кто знает, что такое CSR и как его сделать. В любом случае обратите внимание на то, что размер ключа (Keysize) не должен быть менее 2048 бит.

Предположим, что выбран вариант с генерацией ключа. Тогда заполните форму и нажмите «Continue». После некоторой паузы вы получите свой ключ. Сохраните его, он пригодится позже.

На следующем шаге повторно выберите домен. Далее, укажите для него поддомен. Сертификат будет действителен для выбранного домена и указанного сабдомена (например, www).

На следующем шаге просто подтверждается заказ сертификата. После этого вы получите сам сертификат (PEM-encoded). Сохраните его.

Процесс получения сертификата на этом завершен. В результате у вас есть 2 файла: приватный ключ и сертификат. Их нужно указать в конфигах вашего веб-сервера. Приватный ключ необходимо предварительно расшифровать командой:

openssl rsa -in ssl.key -out ssl.key

О том, как настроить веб-сервер для использования полученного сертификата, как-нибудь в следующий раз. А вообще, по этой теме хватает информации в Интернете.

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

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

И вот, учитывая это, возникает вопрос: если полностью защитить трафик мы не можем, то можем ли мы защитить хотябы самое важное? Например, пароль. В принципе, можем, но тоже не на 100%. Пароль можно хэшировать до передачи на сервер JavaScript-ом. Тогда перехватчик получить хэш. Он сможет по нему авторизоваться, но сам пароль не увидит. Правда, его можно подобрать брутфорсом. С шифрованием самого пароля (вместо хэширования) картина примерно та же, только реализация гораздо сложнее.

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

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

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

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

Именно так поступили в Яндексе. У них я подсмотрел способ определения доступности HTTPS. Подгружается JS с https://, который устанавливает флаг в DOM-модели страницы. Форма авторизации ведет себя по разному в зависимости от этого флага.

Хэшировать ли пароль? Это может иметь значение только в одном случае: если у пользователя один пароль на несколько сервисов. Тогда перехватчик не увидит пароля в открытом виде, чтобы использовать его на других сервисах. Но подобрать брутфорсом пароль все равно возможно. Только это уже не так тривиально, как подсмотреть в открытом виде. Так что если вы на стороне пользователя, постарайтесь пароль хэшировать до передачи.

А как делают другие?

Про Яндекс я уже рассказал. Добавлю, что пароль он передает в открытом виде и не пускает на главную страницу портала по HTTPS.

Mail.ru ведет себя как Яндекс, только их способа определения поддержки HTTPS я не нашел (хотя и не глубоко искал).

Google работает по HTTPS нормально. Пароль передает в открытом виде. Авторизацию по умолчанию предлагает защищенную. Способов определения, поддерживает  ли клиент HTTPS, я не нашел.

Facebook, как и Google, прекрассно работает по HTTPS. Авторизация по умолчанию защищенная. Пароль в открытом виде.

Вконтакте, Одноклассники, TUT.BY и Onliner.by по HTTPS не отвечают, защищенную авторизацию не предлагают, пароль идет в открытом виде.

oz.by по HTTPS предлагает принять самоподписанный сертификат, чтобы потом произвести редирект на HTTP. Пароль в открытом виде.

Вот такая статистика. Западные ресурсы и пользователи давно освоили основы безопасности в сети. Ведущие российские ресурсы защищают хотябы авторизацию пользователя. Ведущие белорусские ресурсы безопасность пользователей игнорируют полностью.

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

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

А как они это делают? Обычно — по тому же каналу, по которому далее будет идти защищенный трафик. Причем обмен ключами происходит в открытом режиме. В случае HTTPS ключ сервера связан с сертификатом, который пользователю предлагается просмотреть и принять. И вот этот сертификат как раз и может перехватить любой промежуточный сервер, на пути которого идет сертификат в открытом виде (прокси, роутер).

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

Если пользователь принимает сертификат-подделку, то трафик будет идти по следующей схеме:

клиент <= SSL-соединение => сервер-прослушка <= SSL-соединение => сервер назначения

Т.е. промежуточный сервер будет получать весь ваш «защищенный» трафик в открытом виде. Стоит также заметить, что передача сертификата происходит в начале каждой сессии HTTPS.

В случае защищенного SSH при первом соединении с сервером на клиенте сохраняется ключ сервера, а на сервере — ключ клиента. Эти ключи передаются между данными клиентом-сервером только один раз, при первом подключении. Если в этом случае SSH-трафик попытаются перехватить, то и клиент, и сервер откажут в соединении из-за несоответствия ключей. Так как ключи можно перенести между клиентом и сервером обходным путем (по защищенному каналу или на внешнем носителе), этот способ соединения является относительно безопасным. Его могут лишь заблокировать, заставив пользователя работать в открытую.

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

Но пути спасения от тотальной слежки есть. Через установленное SSH-соединение можно направлять любой нужный трафик, который с SSH-сервера будет уже в открытом виде идти на конечную точку. Этот способ называется SSH-туннелинг (tunneling). Так можно обезопасить прохождение трафика по незащищенному каналу, но имеет смысл такой подход только при наличии доверенного сервера с поднятым и настроенным на туннелинг SSH-демоном. Причем организовать это достаточно просто. SSH-клиент подключается к серверу, настраивается на прослушку любого данного порта на локальной машине. Этот клиент будет предоставлять услугу SOCKS5-прокси, т.е. его использование можно настроить в любом браузере, почтовых программах, IM-ах и т.д. Через SSH-туннель пакеты попадают на сервер, а с него уходят на целевой сервер. Схема получается следующая:

[localhost: клиент <=> proxy] <== SSH-соединение ==> сервер <=> целевой сервер

Другой способ защиты трафика — VPN-канал. В использовании он проще и удобнее SSH-туннелинга, но в первичной установке и настройке сложнее. Основное удобство этого способа в том, что в программах не нужно прописывать прокси. А некоторый софт и вовсе прокси не поддерживает, следовательно только VPN и подойдет.

На практике есть два варианта работы. Первый — покупка VPN-акканута, который продается специально для этих целей (шифрование трафика по небезопасному каналу). В этом случае продаются обычно аккаунты, соединяться с которыми надо по протоколам PPTP (обычный VPN, который реализован, например, в Windows) или L2TP. Купить такой аккаунт можно, например, на russianproxy.ru.

Второй вариант — покупка VDS-сервера (виртуальный выделенный сервер) с любым дистрибутивом линукса на борту и поднятие на нем VPN-сервера. Один из самых популярных российских провайдеров — firstvds.ru. Его главное преимущество — низкие цены (акцентирую внимание на то, что серверы в России; если подойдет американский сервер, есть, например, vpsland.com, только не забывайте про заокеанские пинги). На VDS ставят OpenVPN-сервер, а на компьютере поднимается OpenVPN-клиент. Для Windows есть даже гуишная версия клиента.

Если вы решите использовать вариант с OpenVPN, то есть простая пошаговая инструкция по поднятию сервера, как раз для firstVDS с Debian на борту. Установить клиента еще проще, особенно под Windows. Отметить стоит только один нюанс. Если весь трафик требуется пустить по созданному VPN-соединению, то требуется прописать default gateway на шлюз VPN (параметр redirect-gateway в конфиге клиента), а если только часть трафика (на определенные хосты), то можно прописать обычные статические маршруты на данные хосты (по IP; например, route add -p 81.25.32.25 10.7.0.1).

Для соединения OpenVPN обмен ключами происходит в ручном режиме, т.е. транспортировать их от сервера на клиент можно абсолютно безопасно.

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