сервера, завірений цифровим підписом центру сертифікації;
випадкову послідовність (RAND_SERV).
. Клієнт перевіряє отриманий сертифікат сервера за допомогою відкритого ключа центру сертифікації, який йому відомий. При негативному результаті перевірки сесія закривається, а при позитивному - клієнт виконує наступні дії:
генерує випадкову 48-байтную послідовність Pre_MasterSecret, призначену для генерації загального секретного майстер-ключа; шифрує Pre_MasterSecret з відкритого ключа сервера, отриманому в сертифікаті сервера, і посилає серверу;
за допомогою узгоджених хеш-алгоритмів формує загальний секретний майстер-ключ (MasterSecret), використовуючи в якості параметрів послідовність Pre_MasterSecret, послану сервера випадкову послідовність RAND_CL і одержану від нього випадкову послідовність RAND_SERV;
використовуючи MasterSecret, обчислює криптографічні параметри SSL-сесії: формує спільні з сервером сеансові секретні ключі для симетричного шифрування й обчислення хеш-функцій;
переходить в режим захищеної взаємодії.
. Сервер розшифровує отриману послідовність Pre_MasterSecret за своїм закритому ключу і виконує на її основі ті ж операції, що і клієнт:
за допомогою узгоджених хеш-алгоритмів формує загальний секретний майстер-ключ (MasterSecret), використовуючи в якості параметрів Pre_MasterSecret, а також послану клієнту випадкову послідовність RAND_SERV і одержану від нього випадкову послідовність RAND_CL;
використовуючи MasterSecret, обчислює криптографічні параметри SSL-сесії: формує загальні з клієнтом сеансові секретні ключі для симетричного шифрування й обчислення хеш-функцій;
переходить в режим захищеної взаємодії.
Так як при формуванні параметрів SSL-сесії і клієнт, і сервер користувалися одними і тими ж вихідними даними (узгодженими алгоритмами, спільної секретної послідовність Pre_MasterSecret і випадковими послідовностями RAND_CL і RAND_SERV), то очевидно що в результаті описаних вище дій вони виробили однакові сеансові секретні ключі. Для перевірки ідентичності параметрів SSL-сесії клієнт і сервер посилають один одному тестові повідомлення, зміст яких відомо кожної зі сторін:
клієнт формує повідомлення з власних посилок на адресу сервера на кроці 1 та посилок, отриманих від сервера на кроці 2, вносячи елемент випадковості у вигляді послідовності MasterSecret, унікальною для даної сесії; формує код для перевірки цілісності повідомлення (MAC), шифрує повідомлення за загальним сеансовому секретному ключу й відправляє серверу;
сервер, у свою чергу, формує повідомлення з власних посилок на адресу клієнта на кроці 2, посилок, отриманих від клієнта на кроці 1, і послідовності MasterSecret; формує код для перевірки цілісності повідомлення (MAC), шифрує повідомлення на загальному сеансовому секретному ключі і відправляє клієнту;
у разі успішної розшифровки і перевірки цілісності кожної зі сторін отриманих тестових повідомлень, SSL-сесія вважається встановленої і сторони переходять в штатний режим захищеної взаємодії.
У процесі захищеної взаємодії із встановленими криптографічними параметрами SSL-сесії виконуються наступні дії:
кожна сторона при передачі повідомлення формує МАС-код для подальшої перевірки цілісності повідомлення і потім зашифровує вихідне повідомлення разом з МАС-кодом по сеансовому секретному ключу;
кожна сторона при прийомі повідомлення розшифровує його і перевіряє на цілісність (обчислюється поточний МАС-код і звіряється з МАС-кодом перевірки цілісності, отриманим разом з повідомленням); у разі виявлення порушення цілісності повідомлення, SSL-сесія закривається.
Незважаючи на те, що протокол SSL підтримується програмним забезпеченням серверів і клієнтів, що випускаються провідними західними компаніями, у нашій країні є обставини, що перешкоджають поширенню даного протоколу та прийняття його в якості базового для реалізації програм, що вимагають захищеного інформаційного взаємодії беруть участь. Практично всі існуючі продукти, що підтримують протокол SSL, реалізовані в США і через експортних обмежень доступні тільки в усіченому варіанті (з довжиною сеансового ключа 40 біт для алгоритмів симетричного шифрування і 512 біт для алгоритму RSA, використовуваного на етапі встановлення SSL-сесії), що на сьогоднішній день явно недостатньо.
3. Побудова VPN на основі Windows Server 2003
3.1 Налаштування сервера VPN під Windows 2003 Server
Проаналізувавши всі можливі варіанти побудови VPN мережі ми зробивш...
