Крайната цел на този handshake е да се договори т.н. session key между клиента и сървъра, който session key да се използва от тук нататък за криптиране на комуникацията между тях.
Другото уточнение е, че тук имаме т.н. „One-Way SSL“, тоест само сървъра се представя със сертификата си, не и клиента.
The ‘client hello’ message: Клиентът изпраща „client hello“ съобщение към сървъра, което съобщение съдържа версията на SSL/TLS, която поддържа клиента, т.н. „cipher suites“ (алгоритмите), които поддържа, и рандъм стринг, т.н. „client random.“
The ‘server hello’ message: Сървърът отговаря на клиента със т.н. „server hello“ съобщение, съдържащо сертификата му, избраният „cipher suite“ и т.н. „server random“ – рандъм стринг, генериран от сървъра.
Authentication: Клиентът проверява сертификата на сървъра по Chain of trust
The premaster secret: Ако всичко с идентичността на сървъра е ОК, клиентът генерира нов рандъм стринг, криптира го с public-a на сървъра и му го изпраща, това е т.н. „premaster secret„. Демек, казва му, „ОК, видях че си този, за който се представяш“.
Private key used: Сървърът го декриптира със своя private ключ.
Session keys created: Сега вече и клиентът и сървърът имат така да се каже, по един комплект от: рандъмите и на двамата както и „premaster secret“-а. Използвайки ги и двамата генерират т.н. „session key“ като и при двамата резултатът трябва да е еднакъв.
Client is ready and Server is ready: Имайки този session key, двамата си изпращат един на друг стрингът „finished„, криптиран с него. Щом и двамата го декриптират и получат „finished„, значи и двамата имат еднакъв „session key„.
Всяка комуникация между двамата вече ще е криптирана с този „session key„, което е Symmetric encryption.
Излиза че Asymmetric encryption се използва само по време на handshake, после всичко си е по Symmetric encription.
Kaкво е cipher suite?
Набор от encryption algorithms, които могат да се използват за установяване на сигурна връзка. По време на т.н. „SSL/TLS handshake“ една от задачите е избиране на алгоритъма, който ще се използва.
PGP е технология за предаване на криптирани съобщения, като e-mail-и например. Използва се най-вече при Web of trust метода на удостоверяване.
Какъв действа:
имаме изходното съобщение, което трябва да криптираме и предадем на получателя.
генерира се рандъм ключ, с който съобщението се криптира.
отделно, трябва да имаме public ключа на получателя, с който да криптираме и нашият рандъм ключ. Защо да криптираме нашият рандъм ключ? Защото ако го изпратим некриптирарн, някой прехващач просто ще си го вземе и ще ни декриптира съобщението. Все едно да си заключа апартамента и да закача ключа на гвоздей до вратата.
така, вече имаме две криптирани неща – самото съобщение, криптирано с рандъма, и рандъма, криптиран с public-a на получателя.
изпращаме на получателя тези две неща като едно съобщение
получателят като ги получи, декриптира първо рандъма, използвайки неговият private ключ.
като има декриптиран рандъма, може да декриптира и самото съобщение, криптирано с рандъма.
Добър въпрос би бил, защо ни е този рандъм ключ, не може ли просто да криптираме съобщението с public-а на получателя и после той да си го декриптира с неговия private ключ?
Не знам, най-вероятно за да може всяко съобщение (e-mail например) да е криптирано по уникален начин, с уникален рандом ключ, а не всеки път – по един и същ начин.
Важно е, public ключа, с който криптираш и изпращаш, да е сигурно, че принадлежи наистина на този, на който изпращаш, а не просто, дават ти някакъв public и хайде кодирай и пращай. За това вече идва пак добрият стар Chain of trust.
На практика са препокриващи се понятия, в смисъл, че обикновено една и съща компания извършва и двете действия – и проверка дали заявителят на сертификата е ОК, и ако да – регистрира сертификата.
RA is purely an entity that verifies the credentials of an applicant.
CA is purely an entity that issues certificates.
Put simply, a CA is purely an entity that issues certificates, and a RA is purely an entity that verifies the credentials of an applicant; Acting as a RA, entities such as Thawte verify you are entitled (in their opinion, of course) to have a certificate issued, then as a CA they issue it.
Validation Authority само дава информация дали сертификатът е валиден. VA не може да издава, нито да ревоква сертификати и трябва редовно да бъде информирана от CA за CLR (Cerificate Revocation List).
Domain validated certificate сертификатът е пак X.509 сертификат, при който за удостоверяване пред CA се използва доказване, че домейнът е на този, който иска сертификата.
The sole criterion for a domain validated certificate is proof of control over whois records, DNS records file, email or web hosting account of a domain. Typically control over a domain is determined using one of the following:
Response to email sent to the email contact in the domain’s whois details
Response to email sent to a well-known administrative contact in the domain, e.g. (admin@, postmaster@, etc.)
Publishing a nonce provided by an automated certificate issuing system
При такива сертификати обикновено се познават веднага по цвета на катинарчето – сиво (само за Хром и Хромиум е зелено).
Extended validated certificate също е X.509 сертификат само, че там изискванията на CA за да го подпише са по-различни. Extended Validated сертификати се издават на името на човек или компания, за което съответно на CA трябва да се даде поне минимална инфомация.
При symmetric encryption един и същ ключ се използва както за криптиране, така и за декриптиране на информацията. Следователно този ключ трябва да се пази таен само между двете страни.
Това не е особено подходящо, защото ако трябва да го раздаваш на много отсрещни страни, се губи елементът на секретност. Всеки, който има този ключ ще може да послушва връзката.
E да, той няма да е вечно един и същ, пак ще е per connection basis, но все пак…
При asymmetric encryption (или public key encryption) за криптиране ти трябва public ключа, а за декриптиране – private ключа. Следователно, и да имат public ключа, ще могат да подслушват трафика, но няма да могат да го разбират (декриптират). Само сървъра ще разбира какво „му говорят“, защото само той има private ключа.
Но това пък значи, че информацията ще може да се криптира само в едната посока, към този, който има private ключа.
Да, и затова asymmetric encryption се използва часто само за да се установи т.н. session key, и с него да се премине пак към symmetric encryption.
Основната идея е да има няколко доверени компании или институции, които да гарантират, че даден публичен ключ наистина принадлежи на този, който твърди, че е негов.
Такива институции се наричат Certificate Authorities (CA) и са организирани иерархично, като на върха стоят т.н. Root Certificate Authorities – такива като DigiCert, Comodo, GoDaddy, GlobalSign и др.
A самата проверка става с процес, наречен Chain of Trust.
Web of trust
Тук принципът е близък до certificate authority с разликата, че няма certificate authorities и сертификатите са self-signed. Web of trust може да се оприличи на малки групи от взаимно имащи си доверие участници и няма нужда от централизирана CA да проверява идентичността им. Удобен е например в рамките на фирма или друга група участници и няма нужда от глобална CA.
Simple public key infrastructure
Тук основната задача е потребителят да бъде ауторизиран, не аутентикиран, т.е. да се определи не кой е и дали е този, който твърди, че е, а какви са му правата. Така, идеята е не да свързват публичен ключ с идентичност, а публичен ключ с права. …a new kind of certificates linking together authorization information and public keys instead of identities and public keys… The reasons for doing so are that global names ( or identities ) are difficult to obtain and computers may need to take decisions based on the identification information a certificate carries. Instead of relying on the names, SPKI relies on public keys and makes life simpler to people developing authorization systems based on PKI.
Също е важно един SPKI сертификат да носи колкото може по-малко инфо за човекът, на който принадлежи. Допуска се дори анонимност.
Форматът трябва също да е максимално опростен. SPKI използва т.н. S-expressions, например: (name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese)
Tук, така да се каже, на почит е ключът, не този на който принадлежи. В какъв смисъл? В смисъл, че ключът е този, който има значение за ауторизирането, не на човекът. Тук няма CA, съответно няма chain of trust… просто има един ключ и един човек, закачен към него.
Къде се използва PKI?
Secure Web Servers SSL/TLS протоколът използва PKI сертификати за сигурно сървиране на интернет – HTTPS
SSH Аутентикирането на потребител в сървър може да използва PKI сертификати.
Email Signing and Encryption За да може да се изпращат secure emails. Има стандарт (S/MIME), който специфицира emails, подписани с X.509 сертификат.
X.509 е стандарт, задаващ формата на сертификати с публичен ключ. Съдържа публичен ключ и идентификатор (хост, организация, фирма, отдел…) и е подписан от Certificate Authority (може да е self signed).
Когато е подписан от Certificate Authority (CA), този който има сертификата, може спокойно да използва публичният му ключ за сигурна комуникация, или да валидира инфомация, криптирана със съответният private key, дали наистина са подписани с него.
X.509 сертификатите могат да имат следните разширения:
.pem – base64 кодиран, затворен между ––BEGIN CERTIFICATE–– и ––END CERTIFICATE––
.cer, .crt, .der – сертификати в двоична DER форма
.p7b, .p7c
.p12
.pfx
PKCS#7 – стандарт за криптиране на информация. PKCS#12 – създаден за да може да комбинира public и private ключовете в един файл.
In addition to the standard X509 *.cer certificates there are also certificate files ending with *.PFX or *.P12. The later ones are X509 certs as well, but may in addition contain a private key, too. Password protected, of course.
The container format used here is called PKCS#12. More info on this is available e.g. in Wikipedia. The reason, that there are two file extensions is historical. PFX was a Microsoft extension, while P12 was the Netscape one.
Certificate chains and cross-certification
Начин на иерархична организация на сертификатите при който всеки сертификат се явява наследник на друг, подписан от т.н. Certificate Authority, като има и т.н. root certificates, които са издадени също от Certificate Authority, които стоят на върха на веригата и са self signed.
Този механизъм се реализира чрез следните свои характеристики:
полето Issuer на всеки сертификат (освен root сертификатите) съвпада с полето Subject на „по-горният“ сертификат във веригата
и не само това, ами и самият сертификат трябва да е подписан със secret key-я на „по-горния“ сертификат. По този начин един сертификат може да се удостовери с публичният ключ на „по-горният“ сертификат.
най-горният, последният сертификат във веригата се приема за достоверен, защото е издаден от Root Certificate Authority
И тук заглавието е подвеждащо, защото нама такова нещо като PEM сертификат. Правилно е да се каже PEM кодиран сертификат.
Подобно на DER, PEM (Privacy Enhanced Mail) сертификат означава X.509 сертификат, но кодиран като base64 текстов файл, а не двоичен.
Kaто PEM може да бъде кодиран не само сертификат, но и certificate signing request.
Ето примерен формат на PEM сертификат:
-----BEGIN CERTIFICATE-----
... base 64 encoding of the DER encoded certificate
with line endings and padding with equals signs ...
-----END CERTIFICATE-----
Или примерен certificate signing request:
-----BEGIN CERTIFICATE REQUEST-----
... base 64 encoding of the DER encoded certificate signing request
with line endings and padding with equals signs ...
-----END CERTIFICATE REQUEST-----
PEM се използва също и за кодиране на public и private ключове, тогава хедър и футър редовете са:
Tук самото заглавие не е точно, защото няма такъв тип сертификати. Правилно е да се каже DER кодиран сертификат. DER е начин за кодиране на сертификат, подобно на PEM, с тази разлика, че DER е двоично кодиране, а PEM е base64 ASCII кодиране.
И DER, и PEM са X.509 формат сертификати, просто едното е в двоична форма, другото в текстова.
Има команди за показване на съдържанието и на едните, и на другите както и трансформация от едно кодиране към друго, и обратно.
Друг вариант на DER двоично кодиран сертификат е CER или CRT.
DER начинът на кодиране може да се използва не само за кодиране на сертификати.
SSH протоколът работи по клиент-сървър модела и отговаря за криптиране на информацията и аутентикацията между тях.
Клиентът е отговорен за началният handshake, уговаряне на начинът на криптиране, аутентикиране.
Сървърът е отговорен да слуша определен порт (по подразбиране 22), да участва в първоначалният handshake с клиента и да уговори начинът на криптиране, да аутентикира клиента.
SSH сесия се установява на два отделни етапа – 1) първо трябва да се договори начинът на криптиране на връзката, 2) тогава вече следва аутентикацията по тази криптирана връзка и 3) след това самата обмяна на информация.
Демек, нищо не става преди първо да се договори начинът на криптиране. И от там нататък, всичко – криптирано.
Negotiating Encryption for the Session: 1.1. когато се установи TCP връзка, сървърът изпраща на клиента какви версии на SSH поддържа. Ако клиентът не поддържа никоя от тях, връзката се прекъсва. Сървърът предава на клиента също и своят public host key, с който клиентът може да разбере дали това е сървърът, към който наистина иска да се свърже (спомни си Chain of Trust). 1.2. следва договаряне на т.н. session key използвайки Diffie-Hellman algorithm. This algorithm (and its variants) make it possible for each party to combine their own private data with public data from the other system to arrive at an identical secret session key. Този ключ е симетричен, демек използва се както за криптиране на изходящите, така и декриптиране на входящите съобщения. Пак не забравяме – всичко това е само per session и само между сървъра и един клиент. Веднъж договорен между двете страни, може да се пристъпи към аутентикация.
Authenticating the User’s Access to the Server: 2.1. Може да стане с парола, която сървърът изисква от клиента и клиентъ я изпраща, криптирана с установеният преди ключ. Това обаче не е достатъчно сигурно. 2.2. По-сигурен метод е използването на SSH key pairs, които са асиметрични, тоест с private ключа можеш само да декриптираш, а с public – само да криптираш. Публичният ключ, както личи от името му, може да се раздава свободно, защото няма начин да се получи private ключа от него.
SSH има няколко начина за криптиране/декриптиране на транспортираната информация.
Symmetrical Encryption
Вид кодиране, при което с един и същ ключ (представляващ най-вероятно някакъв хеш стринг) може да се криптират и декриптират съобщенията между страните в комуникацията. Демек, всеки, притежаващ съответният ключ може да участва в комуникацията.
Този тип кодиране се нарича още „shared secret“ кодиране или „secret key“ кодиране.
Този тип кодиране може да се използва за криптиране на цялата връзка, не само за криптиране при аутентикация.
Как се създава този ключ? Създва се от клиента и сървъра с процес, наречен „key exchange algorithm“. Това е процес, които е само между сървъра и клиента, и при който и сървърът, и клиентът, независимо един от друг изчисляват въпросният ключ, на базата на някаква публична информация. Важно е да се знае, че изчисленият ключ е session based и веднъж изчислен от страните в комуникацията, всяка последваща разменена информация трябва да е криптирана с него. Включително и аутентикацията, тоест всичко това става преди аутентикацията.
Asymmetric Encryption
Тук вече ни трябва двойка public/private ключ за да можем да изпратим успешно информация в една връзка.
Private ключа трябва да се пази тайно, той е единственият, с който може да се декриптира информация, криптирана със съответният public ключ. Public ключа може свободно да се споделя с тези, които искат да комуникират със сървъра и от public-a не може да се получи private ключа.
Щом някой може да декриптира информацията, значи има private ключа.
Важно е да се знае, че public ключа може само да криптира, но не и да декриптира, дори и своите съобщения не може да декриптира. Нито може да декриптира съобщенията, криптирани и изпратени му от съответният му private ключ.
Hashing
Използва се за проверка дали изпратената информация не е променена. Заедно с оригиналното съобщение се изпраща и неговият хеш (message authentication code – MAC). Може да има и предварително споделена секретна дума ако използваме HMAC.
Декодиране на полученият хеш както е известно, е невъзможно.
Този начин (hashing) се използва основно за верифициране дали информацията не е променена по пътя.
Authentication е все едно „логването“, тоест, да се легитимираш , най-често използвайки е-mail или потребителско име и парола, за да може сървът да провери дали има такъв регистиран и валиден потребител при него.
Authorization е дали при следващ request (следващ, демек след Authentication) наистина си ти, който си се логнал и ако да, да ти върна ли респонс.
При Authentication се сетва cookie с хедъра Set-Cookie с някакво session ID.
При Authorization клиентът, вече имайки това cookie, го изпраща с хедъра Cookie за да покаже кой е.
Но и не само това. В какъв смисъл?
В смисъл такъв, ОК влязъл си, искаш да првиш това или онова, но дали имаш право на това или онова? Това, че си влязъл не ти дава пълни права за всичко. Едно приложение има различни „области“, и различните потребители може да бъдат ограничени откъм права, според дадената област.
Демек, не само дали наистина си ти, който преди малко си се логнал, но и на ниво access level дали имаш право да правиш това и онова.
Authentication determines who you are, authorization determines what you can do.
Authentication verifies the identity of a user or service, and authorization determines their access rights.
After users are authenticated, authorization is a matter of determining what level of access authenticated users should have. For instance, the system admin of a web application has typically more access than a regular user.
Хеширането е едностранно, даден стринг например, веднъж хеширан, не може да се де-хешира. То е все едно една торта да я върнеш обратно до яйца, мляко, захар, брашно…
Енкриптването е двустранно, там идеята е веднъж екриптнат даден стринг например, да може да се декриптира обратно.
