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

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

Итак. Алгоритмы шифрования бывают симметричные и ассиметричные. Симметричный алгоритм представляет из себя один единственный ключ(и/или пароль) с помощью которого некоторый набор данных может быть зашифрован и с помощью этого же ключа он может быть расшифрован. Соответственно этот ключ является серкретным и для безопасного обмена данными должен быть распространен между участниками обмена по безопасным каналам вручную заранее до сеанса обмена. Учитывая ограничения алгоритма, в основном он используется в таких программах, как шифрование диска(truecrypt, diskcryptor) и подобных. Основные представители этого алгоритма: DES, AES, IDEA, RC4. Типичные размеры ключей 64, 128, 192 или 256 бит.

Ассиметричный алгоритм использует пару ключей - открытый и закрытый. Открытый ключ секретом не является и может распространяться свободно, тогда как закрытый ключ должен быть защищен от посторонних. Основная идея такой системы, что с помощью открытого ключа можно зашифровать данные и расшифровать их получится только закрытым ключем. Таким образом, сторона А может передать стороне Б свой открытый ключ и сторона Б сможет зашифровать с помощью него данные и отправить стороне А, которая в свою очередь сможет эти данные расшифровать своим закрытым ключем. У данного алгоритма есть одна интересная особенность, которая используется в цифровых подписях(о них ниже): данные зашифрованные закрытым ключем, могут быть расшифрованы открытым ключем, запомним эту особенность. Основные представители этого алгоритма: RSA, ECC. Типичные размеры ключей RSA 512, 1024, 2048.

Есть еще такая штука как Хеш(контрольная сумма, отпечаток, digest) - это такой алгоритм, который с помощью математики может сгенерить строку фиксированной длины для любого объема данных. Т.е. берутся нужные данные(любого объема) и используя один из алгоритмов вычисляется хеш этих данных, т.е. некоторая строка фиксированной длины, которая не зависит от размера данных. При малейшем изменении исходных данных хеш меняется. Хеши используются для контроля целостности данных, когда шифрование самих данных не нужно. Хеш сам по себе не гарантирует, что по пути данные не были злонамеренно подменены, т.к. злоумышленник может подменить данные и сгенерить новый хеш, но зато он гарантирует что данные не были испорчены по пути из-за технических сбоев, ведь если по пути данные были хоть немного повреждены(либо сам хеш), то на стороне получателя это будет выявлено при проверке. Наиболее известные представители: MD5 (Message Digest 5), SHA-1, SHA-224, SHA-256, SHA-384 и SHA-512. Пример хеша MD5: d29aaa0b9cd402b4bfe2395a805f9ada.

Особенность ассиметричного алгоритма используется для технологии цифровых подписей, т.е. когда данные могут быть зашифрованы закрытым ключем, а расшифрованы его открытым ключем. Цифровые подписи используются не для защиты данных от прочтения посторонними, а для гарантирования того, что данные, во-первых, получены от идентифицированно источника(от того, за кого он себя выдает), во-вторых, в неизмененном виде. Достигается это следующим путем: отправитель с данных снимает отпечаток(хеш) и вместе с данными шифрует закрытым ключем(подписывает). Теперь принимающая сторона, во-первых, расшифровывает данные открытым ключем - данный факт подтверждает, что данные были зашифрованы закрытым ключем, который есть только у отправителя, а значит данные точно получены именно от него, а не от кого другого. Во-вторых, сверяет расшифрованные данные с отпечатком(хешем), если они совпадают, значит данные не были изменены или испорчены по пути. Злоумышленник может перехватить данные и расшифровать их(т.к. открытый ключ свободно доступен), но он не может подменить данные, т.к. для этого ему надо сгенерить новый отпечаток и зашифровать его месте с данным обратно, но закрытого ключа у него нет. Таким образом, цифровая подпись гарантирует, что данные получены в неизменном виде и именно от того, от кого мы ожидали(не рассматривает тот вариант, когда закрытый ключ украден). Наиболее распространенные алгоритмы RSA-MD5, RSA-SHA-1, RSA-SHA-256, RSA-SHA-384, DSA и ECDSA. Есть еще такая разновидность цифровых подписей(как я понял) аутентификационный код сообщения (Message Authentication Code, MAC), тоже бывает разных типов в зависимости от используемого алгоритма хеширования.

Есть еще такая штука, как контейнер X.509, который представляет из себя набор данных: открытый ключ, цифровую подпись удостоверяющего центра(СА), уникальное имя и прочую дополнительную информацию. Этот контейнер называется сертификат. Сертификаты бывают самоподписанные и подписанные удостоверяющим центром(СА). Разница лишь в том, что будет ли на вашем сертификате подпись «авторитетного» центра или нет. Аторитетность центра определяется насколько его корневой сертификат известен в раличных операционных системах. CA - корневой сертификат центра сертификации. Взглянем на это с практической стороны. Допустим у нас есть https сервер, мы устанавливаем с ним сеанс связи и наш компьютер пытается проверить его сертификат. Первым делом он ищет в своей локальной базе доверенных корневых сертификатов корневой сертификат того центра, который подписал сертификат веб-сервера. Если такой находится и сертификат действительно был подписан этим центром и при этом сертификат(веб-сервера) не числится в базе отозванных сертификатов, то считается, что все прошло успешно. Если же не нашлось подходящего корневого сертификата(в случае самоподписанного сертификата, либо сертификат был подписан малоизвестным центром, корневой сертификат которого отсутствует в нашей ОС), то пользователь увидит устрашающее сообщение, что подлинность сертификата сервера не удалось проверить. Но в данном случа можно добаваить сертифика в список доверенных и продолжать работать. Итак, еще раз: известный удостоверяющий центр подписывает наш сертификат своим закрытым ключем, открытый ключ удостоверяющего центра(корневой сетификат) уже есть в нашей ОС, как мы помним, именно с помощью открытого ключа можно проверить, действительно ли данные были подписаны тем, кем надо.

Как уже упоминалось выше, сертификат может фигурировать в базе отозванных сертификатов. Хоть у сертификата есть срок действия, может возникнуть ситуация, когда действие сертификата нужно завершить раньше истечения его срока действия. Существуют различные варианты подобных «черных списков» сертификатов. Самый простой: Certificate Revocation List, CRL - база данных отозванных сертификатов, это обыкновенный файл со списком отозванных сертификатов. Его просто использовать с малым числом сертификатов, но в случае с удостоверяющими центрами, подобная база может достигать внушительных размеров и клиенту каждый раз ее скачивать достаточно накладно. Есть альтернативные варианты, например Online Certificate Status Protocol, OCSP - протокол онлайн проверки валидности сертификатов. Это альтеренатива спискам отозванных сертификатов(CRL). Сервис OCSP обязателен только для EV (Extended Validation) сертификатов, для остальных типов опционален. Вся эта система пользовательских сертификатов, центра сертификации и БД отозванных сертификатов называется PKI - Public Key Infrastructure.

Вообще сам по себе ассиметричный алгоритм для шифрования данных не используется из-за достаточно высокого потребления ресурсов. Он используется только на этапе согласования и установки соединения для идентификации участников, после чего уже сам сеанс связи шифруется симетричным протоколом. Но как известно, у симетричного протокола есть проблема с распространением ключей, т.е. они должны быть предварительно предоставлены все сторонам участникам диалога, а это ломает всю логику установки защищенного соединения между двумя случайными собеседниками. Тут на помощь приходит протокол Diffie-Hellman(DH). С помощью этого протокола две стороны(или более) генерят общий секретный ключ не обмениваясь секретными данными, посредством которого в дальнейшем выполняется шифрование передаваемых данных(одним из алгоритмов симметричного шифрования). Этот протокол избавил от необходимости обмениваться секретными ключами по защищенным каналам связи, наоборот на этапе генерации общего ключа все данные передаются в открытую. Но этот протокол уязвим к атаке «человек по середине», т.е. он надежен только в том случае, если данные на этапе генерации не были подменены третьей стороной. Именно для этих целей и используется асиметричный алгоритм, т.е. с помощью цифровых подписей гарантируется неизменность данных на этапе обмена сторон и генерации общего секретного ключа симетричного шифрования. Ну и соответственно после генерации такого ключа дальше уже обмен данными выполняется в зашифрованном виде. Открытые параметры(DH ключ) как правило генерятся на одной стороне(сервером) и при установке сеанса связи передаются другой.

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

• Согласование версии протокола шифрования и прочих параметров(сжатие и т.д.)
• Сервер отсылает свой сертификат с открытым ключем, который клиент может использовать для шифрования сообщений серверверу
• Клиент вычисляет pre-master key, шифрует его открытым ключем сервера и отправляет серверу. Далее обе стороны независимо вычисляют master key
• Клиент шифрует все сообщения, полученные в процессе рукопожатия, и отправляет серверу. Шифруются они ранее выбранным алгоритмом шифрования объемных данных и хешируются MAC. Далее сервер пытается это все расшифровать с
• помощью вычисленного им сеансового ключа, если все получилось, значит все ОК.
• Аналогично поступает сервер. Если клиент смог все расшифроват вычисленным им сеансовым ключем, значит все ОК.
• Соединение можно считать установленным. Все сообщения с этого момента будут передаваться зашифрованными алгоритмом шифрования объемных данных и включать MAC.