TLS и SSL изисква минимум от знания
Какво е SSL и TLS какво?
SSL - Secure Socket Layer, Secure Sockets Layer. TLS - Transport Layer Security, Transport Layer Security. SSL е по-ранна система, TLS се появи по-късно и тя се основава на спецификацията на SSL 3.0, разработен от Netscape Communications. Проблемът обаче в един от тези протоколи - осигуряване на сигурно прехвърляне на данни между два компютъра в Интернет. Тези предавания се използват за различни уеб сайтове, електронна поща, мигновени съобщения и много повече за това, което. По принцип е възможно да се прехвърля никаква информация по такъв начин, за това по-долу.
Защитено предаване се осигурява с помощта на информацията, предавана автентификация и криптиране. По същество, тези протоколи, TLS и SSL, работят по същия начин, няма съществена разлика. Най-TLS, можем да кажем, е наследник на SSL, въпреки че те могат да се използват едновременно, дори и на един и същ сървър. Такава подкрепа е необходима, за да се гарантира, че работата на двете нови клиенти (устройства и браузъри) и с по-стари, които не подкрепят TLS. Последователността на възникване на тези протоколи изглежда така:
Операционната принципа на SSL и TLS
Принципът на функциониране на TLS и SSL, както вече казах същото. На върха на TCP / IP протокол е установено шифрован канал, в който се предават данните за Прилагане протокол - HTTP, FTP, и така нататък. Ето как става това може да бъде представен графично:
протокол за кандидатстване "опакован" в TLS / SSL, а това, от своя страна, TCP / IP. В действителност данните на протокола за прилагане предават по TCP / IP, но те са криптирани. И разшифровате предаваните данни могат да бъдат само на една и съща машина, която е установила връзката. За всички останали, които ще получат предаваните пакети, тази информация ще бъде безсмислено, ако не може да го разчете.
Установяване на връзка се предлага в няколко етапа:
1) Клиентът се свързва със сървъра и изисква защитена връзка. Това може да се осигури или при установяване връзка порт, който първоначално създаден да работи с SSL / TLS, например 443 или искане за допълнителна клиент защитена връзка след инсталация обикновено.
2) При свързването клиент предоставя списък с алгоритми за криптиране, че той "знае". Сървърът проверява получения списък със списък на алгоритми, които "знае" на самия сървър, и избира най-надеждният алгоритъм, а след това казва на клиента, който да се използва алгоритъм
3) сървърът изпраща на клиента цифров сертификат, подписан от сертифициращ орган, както и публичен ключ на сървъра.
4) Клиентът може да комуникира с доверен сертифициращия орган за сървъра, че подписан сертификат на сървъра и да проверява дали сертификатът на сървъра е валиден. Но не може да комуникира. Операционната система е обикновено вече са инсталирани сертификати Root CA, които събират подписите на сертификати на сървъра, като браузъри.
5) генерира ключ на сесия за защитена връзка. Това се прави по следния начин:
- Клиентът генерира случайна цифрова последователност
- Клиентът криптира публичен ключ на сървъра му и изпраща резултата до сървъра
- сървър декриптира получи последователност с частния ключ
Като се има предвид, че на кодиращия алгоритъм е асиметричен, за да дешифрира последователност може само сървър. частни и публични - когато използвате асиметрично криптиране използва два ключа. Публично съобщение, което изпратите е криптирана и разшифрован лично. Разкодирай съобщението с обществеността, тя не може да бъде ключът.
6) Това създава криптирана връзка. Данните, предавани по него, криптиран и разшифрован, докато връзката е прекъсната.
основен сертификат
Заявка за подписване (КСО, Сертификат Вход Заявка)
клиентски сертификат
клиентски сертификат може да бъде генериран за използване в устройства и за потребителите. Обикновено такива сертификати се използват за проверка на дуплекса, когато клиентът потвърждава, че сървърът наистина кой е той твърди, че е и отговорът на сървъра прави същото нещо. Това взаимодействие се нарича двупосочна удостоверяване или взаимно удостоверяване. Двустранна проверка добавя още едно ниво на сигурност, в сравнение с един едностранен, а също може да служи като удостоверяване заместител с помощта на потребителско име и парола.
Верига от действия за издаване на сертификати за генериране
Нека да видим на практика как действията, свързани с образуването на сертификати, от самото начало, и в същото време на практика.
Първото нещо, което да се направи - това е поколението на главния сертификат. Сертификатът за корен е подписан от самия него. И тогава този сертификат ще бъде подписан от други сертификати.
Сега връзката е успешна и ще можете да инсталирате сертификат на сървъра на уеб сървъра, клиентът да изпрати на клиента, и да работи с тях.
безопасност
При използване на SSL / TLS един от основните методи е методът на MITM (човек по средата), «човек в средата". Този метод се основава на използването на някои сертификат на сървъра на сайта и ключ, който ще слуша за трафик и декриптира информацията, обменена между сървъра и клиента. За да слушате на организацията може да се използва, например, една програма sslsniff. Поради това, че главният сертификат и ключ обикновено е желателно да се поддържа машината, която не е свързана към мрежата, да подпише искания да донесе посетителите на флаш паметта, подпишете и просто да вземем. И, разбира се, да направите резервни копия.
Свързани пунктове:
навигация в публикациите
CSR клиент се генерира при поръчка на сертификат, където да се съхранява частния ключ решава клиент да издаде сертификат, ние нямаме нужда от частен ключ и клиент за нас това не предава. Разбира се, ако това се случи на регулярна виртуално, а след това на администратора с корен достъп до сървъра и да има достъп до ключовете, които се съхраняват там.
Това е. Но някои центрове за сертифициране генерират сами КСО, например, WoSign. Клиент и не предава ключа, тя ще се предава само заявка знак. На виртуален сървър от хостинг администратори имат достъп на всички за нищо. Но има едно нещо. Ако използвате пропуск, а след това достъп до ключа за сертификат е безполезна без него. Въпреки, че там е минус. Имате тази фраза, за да се въведе ръцете си, когато стартирате сървъра, така че сървърът не ще бъде в състояние да започне при стартиране на системата.
Относно цици не са оповестени, както е описано PKI технология на работа, няма нищо общо с заглавието на темата. Ако само за това, че позоваване на RFC доведе.
Послепис Имаше един виц за куче и бълхи.
Както се казва, вие отричате - оферта.
При спазване на описаната технология е свързан директно, защото тя е това, което е описано в повечето случаи и се нарича "Как SSL».
Е, според заявление RFC читател:
RFC 6101: Secure Sockets Layer The (SSL) протокол версия 3.0
RFC 5246: Transport Layer Security The (TLS) протокол версия 1.2
И да, вие твърде добре.
зелената линия с името на организацията може да бъде получена само с удостоверението за EV?
Доколкото си спомням, да
Раздел «SSL Принцип и TLS», «Клиентът генерира произволен цифров последователност."
Бях сигурен, че клиентът генерира сесия затвори и, съответно, на публичния ключ (което очевидно ти, и се нарича "цифров последователност"). Публичният ключ се предава към сървъра и сървъра криптира пакети към клиента страна на ключов клиент сесия-отворен.
Предпочитам да даде линк към technet.microsoft.com. «Ключ обмен» раздел. В статията е написано, разбира се, просто би било да се обясни просто принцип на работа, тя не много да навлизаме в подробности.
Като цяло, има различия. Обикновено самостоятелно подписан сертификат корен. И тя се използва само за да подпише други сертификати. Сертификатът на сървъра обикновено подписан от корен или междинно съединение, което се подписва от корена. сертификати Root се разпространяват публично, като част от актуализации за операционната система, сървър не се прилагат. Е, от гледна точка на криптографията на е по принцип едно и също нещо.
Решихме да се превърне тази крива инфекция. Той не е бил там! В контролния панел на хоста изключен. Достъпът до площадката на Изчезналата мрежа изобщо. И все пак хвърля в HTTPS протокол, браузъри и се кълнат:
«Site.ru използва невалиден сертификат за сигурност. Сертификатът не е доверие, тъй като тя е самоподписаният. Сертификатът не е валиден за името site.ru. »
Подкрепа предлага да се възстанови от резервно копие ... сайт!
Така че аз стоя на тротоара, облечени в ски. Или не карате ски или ...
Моля, кажете ми чайника. Това е начинът, по който трябва да работи? Или е криви сертификати с извита конфигурация на сървъри в приемащата, или и двете?
Благодаря. С уважение,
Виталий
Добър ден.
Това не би трябвало да работи ясно. Обикновено в нормален сертификат показва имена DNS, за която е издаден (с и без WWW WWW).
Това, което описваш е или сертификат, в който името на DNS-не е посочено или с заместващи сертификати.
Мисля, че криви сертификатите и настройките от страната-домакин в края на краищата.
Плюс това, че е възможно на сайта zahardkozhen HTTP протокол на различни места, така че съдържанието се показва частично. Тези проблеми са решени или прокси сървъри, или чрез редактиране на сайта.
Благодаря ви, Макс.
Фактът, че сайтът е един от компонентите е станал крива показва поради zahardkozhennogo HTTP, осъзнах, че съм. Но се оказа, че админ панела не е бил там, за да разгледате тези пасажи)))
Множество предлага техническа поддръжка възстановяване от резервно копие))) Вместо това, по мое разбиране, за да се справят с настройките на сървъра, които, въпреки отстраняването на сертификата, все още инициира с HTTPS връзка.
Макар че аз съм се кара с тях, и прочетете за SSL, през което време и имам към сайта си, малко разбрах, как трябва да се работи, и че в действителност не работи правилно.
Благодаря ви за потвърждение на моите предположения. Аз трябва да проучи темата по-нататък.
С уважение,
Виталий
Благодаря. Много достъпни.
Добър ден. Трябва да се генерират нови удостоверения уточняват IP като (областта КН) за името на сървъра, то е едно и също FQDN. С вече генерирани сертификати няма да направи нищо.
Това, в допълнение към сертификата, трябва да влезете в HTTPS? Създаване на уеб сървър? Poke към желаната посока.
Сертификат, ключ, верига сертификати, които подписан сертификат на сървъра (обикновено), и да, конфигуриране на уеб сървъра, трябва да посочите настройките на пътя до файла на сертификата, който е ключов, а понякога и на веригата. Но обикновено, веригата просто приложена към сървъра на сертификат. В статията просто трябва конфигурационни примери Nginx и Apache