Отже, https - це не зовсім окремий протокол, а майже той же http тільки дані будуть проходити шифрування через прошарок безпеки - SSL. Тобто, відправляючи форму входу, твоя пошта та пароль шифруються за допомогою алгоритму, що використовує синхронний ключ і тільки після цього відправляються на сервер. Сервер розшифровує дані і далі працює з ними згідно своєї логіки. І навіть якщо, злодій перехопить дані, він отримає набір, непотрібних йому, біт інформації, котрі треба буде ще розшифрувати, а розшифрувати зможе тільки той, хто встановив з’єднання з сервером.

Як саме встановлюється з’єднання!?

• Клієнт встановлює з’єднання з сервером і запитує захищене з’єднання.

• При встановленні захищеного з’єднання клієнт відправляє серверу перелік алгоритмів шифрування (шифрів), котрі він знає.

• Сервер звіряє цей перелік із своїми шифрами та обирає найбільш надійний і повідомляє клієнта котрий алгоритм буде використовуватися.

• Сервер відправляє клієнту свій цифровий сертифікат, підписаний відповідним центром сертифікації, та відкритий ключ сервера.

• Клієнт перевіряє сертифікат. Він навіть може зробити запит до відповідного центру сертифікації, але зазвичай в ОС вже є набір встановлених кореневих сертифікатів надійних центрів сертифікації з якими браузер звіряє підпис отриманого від сервера сертифіката. Також звіряється, чи не закінчився термін дії сертифіката, чи виданий він для потрібного домена та інші речі.

І тільки після цього генерується сеансовий ключ захищеного з'єднання:

• Клієнт генерує випадковий рядок.

• Клієнт шифрує цей рядок відкритим ключем і відправляє на сервер.

• Сервер розшифровує цей рядок за допомогою приватного ключа.

Останній пункт є основою захищеного з’єднання, тому, що він дозволяє безпечно передати мережею ключ, котрий, в подальшому, буде використаний для шифрування даних за допомогою спеціального алгоритму шифрування, що використовує симетричний ключ. Це потрібно тому, що асиметричний ключ дуже надійний, але повільний, тому використовується тільки для важливих дій, як передача сеансового ключа, чи підтвердження клієнтові достовірності сервера чи навпаки.

Отже, протокол SSL використовує як симетричний, так і асиметричний ключі для шифрування даних. Але ж в чому ж різниця?

Симетричний ключ.

При шифруванні симетричним ключем, використовується один і той же ключ для шифрування та розшифрування даних. Якщо клієнт та сервер хочуть обмінюватися зашифрованими повідомленнями в безпечному режимі, то обидві сторони повинні мати однакові симетричні ключі. Цей недолік, як ти помітив нівелюється за допомогою передачі симетричного ключа зашифрувавши його, за допомогою, алгоритму, що використовує асиметричний ключ. Шифрування симетричним ключем, зазвичай, використовується для шифрування великих об'ємів даних, так як цей процес проходить в сотні, а то й в тисячі разів швидше, ніж при асиметричному шифруванні. Зазвичай використовуються алгоритми DES (Data Encryption Standard - стандарт шифрування даних), 3-DES (потрійний DES), RC2, RC4 чи AES (Advanced Encryption Standard - просунутий стандарт шифрування).

Асиметричний ключ

Шифрування за допомогою асиметричного (відкритого) ключа використовує пару ключів, які обидва були отримані, за допомогою цілого комплексу математичних обчислень. Один з ключів використовується в якості відкритого, як правило, сертифікаційний центр публікує публічний ключ в самому сертифікаті (зазвичай в заголовку - subject). Приватний ключ тримається в таємниці і ніколи, нікому, не показується. Ці ключі працюють в парі. Якщо відкритий ключ використовується для шифрування даних, то розшифрувати їх можна тільки за допомогою приватного ключа. Якщо дані шифруються приватним ключем, то розшифрувати їх можна тільки за допомогою публічного ключа. Таким чином, якщо клієнт шифрує дані за допомогою публічного ключа, то дані може розшифрувати тільки власник приватного ключа - в нашому випадку - сервер. Саме це є основою для цифрових підписів. Найпоширеніший алгоритм, який використовується при шифруванні з асиметричними ключами - RSA (названий на честь розробників Rivest, Shamir, Adleman).

Це основа безпечного з’єднання. Як бачиш нічого складно, загалом як і все на цьому світі…

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Це моя стаття котру я розмістив у себе на css.in.ua.

І у мене виникло питання навіщо треба кореневий сертифікат? Адже він вже влаштований у твою ОС. І якщо твій сертифікат  підписаний чимось невідомим, то сайт без вагань буде позначено як небезпечний. і ніякі додаткові запити не допоможуть. Тільки руками додати в ОС.

Навіщо його просять вказувати в nginx чи apache?

Доки писав, згадав, що сертифікат може бути підписаним проміжним сертифікатом. А отже браузер не зможе підтвердити його валідність. (Чи зможе? У кожного сертифіката вказано ж хто його видав і по цьому ланцюжку можна вийти на кореневий сертифікат) Тому інколи треба вказати цей ланцюжок з проміжних сертифікатів.

Існує chain та fullchain (наш сертифікат та chain в одному файлі). Кому  і навіщо потрібен fullchain?

Власне, хто вже ближче до криптографічної вершини, допоможіть наблизитися до неї і доповнити трохи статтю.