როგორ მუშაობს HTTPS, მარტივი სიტყვებით

HTTPS ჩვეულებრივი HTTP-ა - იგივე მოთხოვნები, იგივე გვერდები - ოღონდ დაშიფრული გვირაბით, სახელად TLS, გადაცემული. გვერდის ერთი ბაიტის გადაცემამდეც კი შენი ბრაუზერი და სერვერი თანხმდებიან საიდუმლო გასაღებზე, რომელსაც ქსელზე დამკვირვებელი ვერ გამოთვლის, ხოლო სერვერი სერტიფიკატით ადასტურებს, რომ ის მართლაც იმ საიტია, რომლის სახელიც შენ აკრიფე. ამის შემდეგ შენსა და სერვერს შორის მყოფი ხედავს მხოლოდ იმას, რომ კონკრეტულ მისამართს დაუკავშირდი და დაახლოებით რა მოცულობის მონაცემი გადავიდა ორივე მიმართულებით. გვერდებს, ფორმებს, პაროლებსა და cookie-ებს ვერ ხედავს და ვერაფრის შეცვლას შეძლებს კავშირის გაწყვეტის გარეშე.

მთელი იდეა ეს არის. ამ სტატიის დანარჩენი ნაწილი განმარტავს, როგორ მუშაობს თითოეული ნაწილი, რას გვპირდება და რას არ გვპირდება ბოქლომი და რატომ სჭირდება HTTPS იმ საიტსაც კი, რომელსაც დასამალი არაფერი აქვს.

HTTP და HTTPS: რა იცვლება სინამდვილეში#

ჩვეულებრივი HTTP ღიად გადაცემული ტექსტია. ავტორიზაციის გვერდის მოთხოვნა ქსელში ზუსტად ისე გამოიყურება, როგორც ბრაუზერმა დაწერა:

POST /login HTTP/1.1Host: shop.example.comContent-Type: application/x-www-form-urlencodedemail=anna%40example.com&password=herring-barrel-42

ყველა მოწყობილობას, რომელიც ამ პაკეტს ატარებს - კაფეს როუტერს, სასტუმროს ქსელურ ყუთს, ინტერნეტ-პროვაიდერს, მათ შორის მდგომ ნებისმიერ მანქანას - შეუძლია მისი წაკითხვა, შენახვა ან გადაწერა. გადაწერა მხოლოდ თეორიული შესაძლებლობა არ არის: პროვაიდერები და საჯარო hotspot-ები წლების განმავლობაში ათავსებდნენ რეკლამებს, თვალთვალის სკრიპტებს და „თქვენი ტრაფიკის ლიმიტი იწურება" ბანერებს ჩვეულებრივ HTTP გვერდებში.

HTTPS ცვლის გადაცემის ფენას და მის ზემოთ არაფერს:

აპლიკაცია არ იცვლება. იგივე სერვერის კოდი, იგივე HTML, იგივე cookie-ები - TLS კავშირს ახვევს, HTTP კი მის შიგნით ისე მუშაობს, რომ ამას ვერც ამჩნევს. ამიტომაც გამოიყენება „SSL" და „TLS" ერთმანეთის მაგივრად: SSL 1990-იანი წლების თავდაპირველი პროტოკოლი იყო, TLS მისი მემკვიდრეა, SSL-ის ყველა ვერსია კი ოფიციალურად გაუქმებულია, როგორც არასაიმედო. რასაც დღეს „SSL სერტიფიკატს" ეძახიან, მხოლოდ TLS-თან გამოიყენება, ამჟამინდელი ვერსიებია TLS 1.2 და TLS 1.3. TLS 1.0 და 1.1 2021 წელს გაუქმდა და თანამედროვე ბრაუზერები მათ უარყოფენ.

დაშიფვრის ორი სახეობა, რომელსაც ის იყენებს#

HTTPS აერთიანებს კრიპტოგრაფიის ორ ოჯახს, რადგან თითოეული კარგია იმაში, რაშიც მეორე სუსტია.

სიმეტრიული დაშიფვრა ერთ გასაღებს იყენებს ჩაკეტვისა და გახსნისთვის. ის საკმარისად სწრაფია, რომ ტელეფონზე ვიდეო რეალურ დროში დაშიფროს. მისი სისუსტე აშკარაა: ორივე მხარეს ერთი და იგივე გასაღები სჭირდება, გასაღებს კი უბრალოდ ვერ გაგზავნი იმავე ქსელში, რომლის დაცვასაც ცდილობ. პრაქტიკაში გამოიყენება AES GCM რეჟიმში და ChaCha20-Poly1305; ორივე მონაცემების ნებისმიერ ცვლილებასაც ამჩნევს, ანუ იჭერს არა მხოლოდ მოსმენას, არამედ გაყალბებასაც.

ასიმეტრიული (public-key) კრიპტოგრაფია გასაღებების წყვილს იყენებს. რასაც ერთი გასაღები აკეთებს, მხოლოდ მეორეს შეუძლია გადამოწმება ან გაუქმება. ერთი ნახევარი საჯაროა და ნებისმიერს გადაეცემა, მეორე კი პირადია და სერვერს არასოდეს ტოვებს. ეს ნელია, მაგრამ ორ რთულ პრობლემას წყვეტს: ორ უცნობს შეუძლია ღია ხაზზე საერთო საიდუმლოზე შეთანხმება, და ერთ-ერთს შეუძლია დაამტკიცოს, ვინ არის, ისე, რომ არაფერი გამოამჟღავნოს, რისი ხელახლა გამოყენებაც შეიძლება.

ამრიგად, HTTPS ნელ, მაგრამ ჭკვიან სახეობას ერთხელ იყენებს დასაწყისში - გასაღებზე შესათანხმებლად და ვინაობის შესამოწმებლად, ყველაფრისთვის შემდეგ კი სწრაფს. შეთანხმების ეტაპი გასაღებების გაცვლაა - პრაქტიკაში ელიფსურ მრუდებზე დაფუძნებული Diffie-Hellman-ის ვარიანტი, მაგალითად X25519. თითოეული მხარე ირჩევს შემთხვევით საიდუმლოს, აგზავნის მისგან მიღებულ მნიშვნელობას, შემდეგ კი ორივე ერთმანეთისგან მიღებულს საკუთარ საიდუმლოსთან აერთიანებს და ერთსა და იმავე რიცხვამდე მიდის. დამკვირვებელს, რომელმაც ორივე მნიშვნელობა გზაში დაინახა, მაინც არ შეუძლია მისი გამოთვლა.

ღირს იმის ცოდნა, რომ თანამედროვე TLS ამ გაცვლის საიდუმლოებს ყოველი კავშირის შემდეგ ანადგურებს. ამას forward secrecy ჰქვია და ნიშნავს, რომ თუ სერვერის პირადი გასაღები მომავალ წელს მოიპარეს, დღეს ჩაწერილი ტრაფიკი მაინც ვერ გაიშიფრება. TLS 1.3-ში ეს სავალდებულოა; ძველ კონფიგურაციებს, სადაც სესიის გასაღები პირდაპირ სერვერის სერტიფიკატის გასაღებით იშიფრებოდა, ეს თვისება არ ჰქონდა.

სერტიფიკატები და სერტიფიკაციის ავტორიტეტები#

მარტო დაშიფვრა საკმარისი არ არის. თუ თავდამსხმელი შენსა და სერვერს შორის დგას, მას შეუძლია შენთან სრულყოფილად დაშიფრული კავშირი აწარმოოს და მეორე - ნამდვილ სერვერთან, შუაში კი ყველაფერი წაიკითხოს. გასაღებების გაცვლა არასწორ მხარესთან წარმატებით დასრულდებოდა. ამას სერტიფიკატი აჩერებს.

სერტიფიკატი პატარა ფაილია, რომელიც საჯარო გასაღებს ერთ ან რამდენიმე სახელს აკავშირებს. მისი მთავარი ველებია:

• Subject alternative names - ჰოსტის სახელები, რომლებისთვისაც ის მოქმედებს, მაგალითად example.com და www.example.com, ან wildcard, როგორიცაა *.example.com, რომელიც ქვედომენის ერთ დონეს ფარავს.
• საჯარო გასაღები - იმ გასაღებთა წყვილის საჯარო ნახევარი, რომლის პირადი ნახევარიც სერვერზეა.
• მოქმედების ვადა - თარიღი „არა უადრეს" და „არა უგვიანეს". ამ ფანჯრის გარეთ სერტიფიკატი უარყოფილია.
• გამცემი და ხელმოწერა - რომელი ავტორიტეტი იძლევა ამ კავშირის გარანტიას და მისი ციფრული ხელმოწერა ყველაფერზე ზემოთ ჩამოთვლილზე.

ავტორიტეტია მთავარი. სერტიფიკაციის ავტორიტეტი (CA) ორგანიზაციაა, რომლის საჯარო გასაღებები შენს ოპერაციულ სისტემაში ან ბრაუზერშია ჩაშენებული სიაში, სახელად root store. Mozilla-ს, Apple-ს, Microsoft-სა და Google-ს თითოეულს თავისი აქვს და აუდიტს უტარებს მასში შემავალ CA-ებს. როცა CA სერტიფიკატს ხელს აწერს, ის აცხადებს, რომ შეამოწმა: მომთხოვნი ამ სახელს აკონტროლებს. უფასო სერტიფიკატებისთვის, რომლებსაც უმეტესი საიტი იყენებს, ეს შემოწმება ავტომატურია: CA მომთხოვნს სთხოვს დომენზე ტოკენი გამოაქვეყნოს და თავად იღებს მას - როგორ მიმდინარეობს ეს გამოწვევა, ზუსტად აღწერილია სტატიაში HTTPS და Let's Encrypt განმარტებით.

Root-ები ოფლაინ ინახება და იშვიათად გამოიყენება, ამიტომ CA შენს სერტიფიკატს შუალედური გასაღებით აწერს ხელს, შუალედურს კი root აწერს ხელს. სერვერი თავის სერტიფიკატს და შუალედურს აგზავნის, root ბრაუზერს უკვე აქვს. ეს არის ჯაჭვი:

ბრაუზერი ამოწმებს თითოეულ ხელმოწერას ზემოთკენ, სანამ root-ს არ მიაღწევს, რომელსაც უკვე ენდობა. თუ რომელიმე რგოლი აკლია, ვადაგასულია ან უცნობის მიერაა ხელმოწერილი, კავშირი გაფრთხილებით უარყოფილია. სერვერი, რომელიც მხოლოდ საკუთარ სერტიფიკატს აგზავნის და შუალედურს ივიწყებს, კლასიკური არასწორი კონფიგურაციაა და ეს განსაკუთრებით გამაღიზიანებელია, რადგან ზოგ ბრაუზერში მუშაობს - იმათში, რომლებმაც შუალედური შემთხვევით სხვა საიტიდან უკვე შეინახეს - ზოგში კი არა.

ყველა საჯარო სერტიფიკატი ასევე ჩაიწერება Certificate Transparency ჟურნალებში - საჯარო, მხოლოდ დამატებადი ჩანაწერებია, რომლებშიც ნებისმიერს შეუძლია ძებნა. ბრაუზერები მოითხოვენ დადასტურებას, რომ სერტიფიკატი ჩაწერილია. შედეგად CA ვერ გასცემს უჩუმრად შენი დომენის სერტიფიკატს სხვა ადამიანზე ისე, რომ კვალი არ დატოვოს, რომლის პოვნაც შენ შეგიძლია.

TLS handshake ნაბიჯ-ნაბიჯ#

როცა https://example.com-ს ხსნი, HTML-ის პირველ ბაიტამდე ეს ხდება. აღწერა TLS 1.3-ს ეხება, რომელზეც თითქმის ყველა ახლანდელი ბრაუზერი და სერვერი თანხმდება; TLS 1.2 იგივე ლოგიკით მუშაობს ერთი დამატებული წრიული მოგზაურობით.

1. TCP კავშირი. ბრაუზერი სახელს DNS-ით პოულობს და ამ მისამართზე პორტ 443-ზე კავშირს ხსნის. (DNS ჩანაწერები განმარტებით მოძიებას აღწერს.)
2. ClientHello. ბრაუზერი აგზავნის TLS ვერსიებს და შიფრებს, რომლებსაც მხარს უჭერს, შემთხვევით მნიშვნელობას, გასაღებების გაცვლის თავის ნაწილს („key share") და ორ მნიშვნელოვან გაფართოებას: SNI - სასურველი ჰოსტის სახელი, რათა სერვერმა, რომელიც ბევრ საიტს ემსახურება, იცოდეს რომელი სერტიფიკატი წარადგინოს; და ALPN - პროტოკოლები, რომლებზეც მას შეუძლია საუბარი, მაგალითად h2 HTTP/2-ისთვის.
3. ServerHello. სერვერი ირჩევს ვერსიას და შიფრს და აგზავნის თავის key share-ს. ამ მომენტში ორივე მხარეს შეუძლია იგივე საიდუმლოს გამოთვლა და აქედან ყველაფერი დაშიფრულია.
4. Certificate. სერვერი აგზავნის თავის სერტიფიკატს და შუალედურ ჯაჭვს.
5. CertificateVerify. სერვერი თავისი პირადი გასაღებით ხელს აწერს აქამდე მიმდინარე მთელი საუბრის ჰეშს. ეს არის ვინაობის დადასტურება: ამ ხელმოწერის შექმნა მხოლოდ სერტიფიკატის შესაბამისი პირადი გასაღების მფლობელს შეუძლია, და რადგან ის ამ საუბრის შემთხვევით მნიშვნელობებს მოიცავს, ძველი საუბრიდან ვერ გამეორდება.
6. Finished. სერვერი აგზავნის მოკლე საკონტროლო მნიშვნელობას მთელ handshake-ზე და ამით ამტკიცებს, რომ გზაში არაფერი შეცვლილა.
7. კლიენტის შემოწმება. ბრაუზერი ამოწმებს ჯაჭვს სანდო root-მდე, თარიღებს, იმას, რომ მისამართის ზოლში არსებული სახელი სერტიფიკატის სახელების სიაშია, და მე-5 ნაბიჯის ხელმოწერას. ნებისმიერი შეცდომა აქვე აჩერებს კავშირს გაფრთხილების გვერდით.
8. კლიენტის Finished, შემდეგ HTTP. ბრაუზერი აგზავნის საკუთარ Finished შეტყობინებას, რომელსაც მაშინვე მოსდევს ჩვეულებრივი GET მოთხოვნა - უკვე დაშიფრული ჩანაწერების შიგნით.

მთელი ეს პროცესი მოთხოვნის გაგზავნამდე ერთ ქსელურ წრიულ მოგზაურობას ხარჯავს - დაახლოებით ისევე, როგორც ერთი ping სერვერამდე. დაბრუნებულ ვიზიტორს შეუძლია წინა სესიის განახლება და სერტიფიკატის ნაბიჯის გამოტოვება, TLS 1.3 კი განახლებისას პირველივე პაკეტში მონაცემების გაგზავნასაც კი უშვებს („0-RTT"), ოღონდ ამ ადრეული მონაცემების გამეორება შესაძლებელია, ამიტომ სერვერები მას მხოლოდ უსაფრთხოდ გამეორებად მოთხოვნებზე იღებენ.

რეალური handshake ტერმინალიდან შეგიძლია დააკვირდე:

# Summary: protocol, cipher, certificate subject and issuer$ openssl s_client -connect example.com:443 -servername example.com -brief < /dev/null# The same from curl, with every TLS step printed$ curl -v https://example.com -o /dev/null

-servername ალამი SNI-ს ადგენს. მის გარეშე სერვერმა, რომელიც რამდენიმე სახელს ემსახურება, შეიძლება რომელიმე სხვა საიტის ნაგულისხმევი სერტიფიკატი დაგიბრუნოს და შედეგი დაზიანებულ სერტიფიკატს ჰგავს, სინამდვილეში კი უბრალოდ ალამი აკლია.

HTTP/3 ქვემდებარე გადაცემას ცვლის - ის TCP-ის მაგივრად QUIC-ზე მუშაობს, UDP პორტ 443-ზე - მაგრამ TLS 1.3 handshake QUIC-შია ჩაშენებული და ზემოთ აღწერილი ნაბიჯები მაინც სრულდება.

რას ნიშნავს ბოქლომი და რას არა#

ბოქლომი, ან ახლანდელ Chrome-ში იმავე ადგილას ნეიტრალური პარამეტრების ხატულა, ზუსტად სამ რამეს ნიშნავს: კავშირი დაშიფრულია, გზაში არ შეცვლილა, და სერვერმა დაამტკიცა, რომ მისამართის ზოლში არსებული სახელისთვის მოქმედი სერტიფიკატი აქვს. ეს განცხადებაა მილის შესახებ და არა იმ ადამიანების შესახებ, ვინც მეორე ბოლოშია.

ის არ ნიშნავს:

• საიტი პატიოსანია. ფიშინგის გვერდი მისამართზე paypa1-secure-login.com მოქმედ სერტიფიკატს წამებში იღებს, რადგან სერტიფიკატი მხოლოდ ზუსტი ამ სახელის კონტროლს ადასტურებს. წაიკითხე სახელი და არა ხატულა.
• კომპანია ის არის, ვინც თავს ეძახის. უფასო, გავრცელებული სერტიფიკატები დომენის დადასტურებულია. უფრო ძვირი ორგანიზაციის დადასტურებული და extended-validation სერტიფიკატები კომპანიის ჩანაწერების შემოწმებას გულისხმობს, მაგრამ ბრაუზერები მისამართის ზოლში კომპანიის სახელს აღარ აჩვენებენ, ამიტომ ვიზიტორი მათ ვერ არჩევს.
• საიტი უსაფრთხოა. HTTPS მონაცემებს გადაცემისას იცავს. ის არაფერს აკეთებს მოძველებული plugin-ის, სუსტი ადმინის პაროლის ან ინტერნეტისთვის ღია დარჩენილი ბაზის წინააღმდეგ. ამ მხარისთვის უკეთესი გზამკვლევია WordPress-ის უსაფრთხოების გამაგრება.
• არავის შეუძლია დაინახოს, რომ ეწვიე. ქსელის დამკვირვებელი მაინც ხედავს სერვერის IP მისამართს და ჩვეულებრივ ჰოსტის სახელსაც: ClientHello-ში SNI დაუშიფრავად იგზავნება, თუ ბრაუზერიც და სერვერიც Encrypted Client Hello-ს არ უჭერენ მხარს, რაც ჯერ ვრცელდება, DNS მოთხოვნა კი ღია ტექსტია, თუ მოწყობილობა დაშიფრულ DNS-ს არ იყენებს. რასაც ვერ ხედავს, არის ბილიკი, query string, headers, cookie-ები და შინაარსი. https://example.com/account/orders?id=4411 example.com-ს ამჟღავნებს; დანარჩენი გვირაბში რჩება.
• შენი დამსაქმებელი ან სკოლა ვერ კითხულობს. კორპორატიულ ქსელებს და ზოგ ანტივირუსულ პროდუქტს მართულ მოწყობილობებზე საკუთარი root სერტიფიკატი აყენია და ტრაფიკს შუაში განზრახ შიფრავს. მოწყობილობაზე, რომელსაც არ აკონტროლებ, ჩათვალე, რომ ეს შესაძლებელია. რას იცავს VPN და რას არა VPN-თან გადაკვეთას განმარტავს.

HSTS: პირველი მოთხოვნის ხვრელის დახურვა#

იმ საიტსაც კი, რომელიც ყველა HTTP მოთხოვნას HTTPS-ზე გადაამისამართებს, აქვს სუსტი წუთი: ყველაზე პირველი მოთხოვნა. თუ example.com-ს აკრიფებ, ბრაუზერი ჯერ http://-ს ცდის და ეს ჩვეულებრივი მოთხოვნა შეიძლება გადამისამართების მოსვლამდე ჩაიჭრას. იმავე wifi-ზე მყოფ თავდამსხმელს შეუძლია თავად უპასუხოს და უსასრულოდ HTTP-ზე გამყოს - ეს downgrade შეტევაა.

HSTS (HTTP Strict Transport Security) ამ ხვრელს ხურავს. სერვერი ერთხელ HTTPS-ზე აგზავნის header-ს:

Strict-Transport-Security: max-age=31536000; includeSubDomains

ამიერიდან max-age წამის განმავლობაში - აქ ერთი წელი - ბრაუზერი ამ სახელზე ყველა http:// ბმულს https://-ად გადაწერს რაიმეს გაგზავნამდე და სერტიფიკატის გაფრთხილებაზე გადასვლის შესაძლებლობასაც აღარ გაძლევს. პირველი ვიზიტი მაინც დაუცველია, ამისთვისაა preload სია: მასში გაგზავნილი სახელები ბრაუზერებში მყარად ჩაწერილია, როგორც მხოლოდ HTTPS, პირველ ვიზიტამდეც კი. ზოგიერთი მთლიანი უმაღლესი დონის დომენი, როგორიცაა .dev და .app, ამ სიაშია, ამიტომ მათ ქვეშ ყველა საიტმა პირველივე დღიდან HTTPS უნდა უზრუნველყოს.

HSTS ერთადერთი HTTPS ფუნქციაა, რომელმაც შეიძლება საკუთარი საიტიდან გამოგკეტოს, თუ რომელიმე ქვედომენს ჯერ კიდევ ჩვეულებრივი HTTP სჭირდება, preload-ის გაუქმება კი ნელია. დაიწყე მოკლე max-age-ით, დარწმუნდი რომ ყველაფერი მუშაობს და მხოლოდ შემდეგ გაზარდე. კონფიგურაცია, გადამისამართებასა და mixed-content-ის გასუფთავებასთან ერთად, რომელიც პირველ რიგში უნდა გაკეთდეს, აღწერილია სტატიაში HTTPS და Let's Encrypt განმარტებით.

რატომ სჭირდება HTTPS ყველა საიტს#

„ჩემს საიტზე ავტორიზაცია და გადახდები არ არის" - ეს ჩვეულებრივი არგუმენტია იმის წინააღმდეგ, რომ თავი შეიწუხო. ის აღარ მუშაობს, მიზეზების გამო, რომლებსაც საიდუმლოებასთან კავშირი არ აქვს.

• ბრაუზერები ჩვეულებრივ HTTP-ს არაუსაფრთხოდ ნიშნავენ მისამართის ზოლში, ყველა გვერდზე. HTTP გვერდებზე ფორმებს დამატებითი გაფრთხილება ემატება, როცა ვინმე აკრეფას იწყებს, ბრაუზერები კი სულ უფრო ხშირად ჯერ HTTPS-ს ცდიან და ჩვეულებრივ HTTP-ზე დაბრუნებამდე აფრთხილებენ.
• გაყალბება მოსაწყენ გვერდებსაც ეხება. სტატიკურ რეცეპტების ბლოგზე ჩაშენებული სკრიპტი ვიზიტორის ბრაუზერში იმავე ძალით მუშაობს, რაც შენი: შეუძლია გადამისამართება, მაინინგი ან ყალბი ავტორიზაციის მოთხოვნის ჩვენება.
• თანამედროვე ფუნქციები მას მოითხოვს. გეოლოკაცია, კამერისა და მიკროფონის წვდომა, service worker-ები, push შეტყობინებები, clipboard API და ბრაუზერებში HTTP/2 - ყველას უსაფრთხო კონტექსტი სჭირდება. ბრაუზერები HTTP/2-სა და HTTP/3-ს მხოლოდ TLS-ზე იყენებენ, ამიტომ მხოლოდ HTTP-ზე მყოფი საიტი ძველ, ნელ პროტოკოლზეც რჩება.
• საძიებო სისტემები მას ამჯობინებენ. Google 2014 წლიდან იყენებს HTTPS-ს რანჟირების სიგნალად. ეს პატარა სიგნალია, მაგრამ არაფერი ღირს.
• Referrer მონაცემები ინარჩუნებს. როცა ვიზიტორი HTTPS გვერდიდან HTTP-ზე გადადის, ბრაუზერი referrer-ს აჭრის, ამიტომ HTTP საიტები ანალიტიკის ნაწილს კარგავენ.
• სერტიფიკატი უფასოა და თავად ახლდება. ფასის არგუმენტი მაშინ გაქრა, როცა უფასო, ავტომატური სერტიფიკატები ნორმად იქცა.

RE:NODE-ის app და web გეგმებზე სამუშაო ერთ DNS ჩანაწერამდე დადის: დაამატე ჰოსტის სახელი proxy slot-ში, მიუთითე A ჩანაწერი იმ მისამართზე, რომელსაც ის აჩვენებს, და სერტიფიკატი გაიცემა, როგორც კი სახელი გადაიჭრება, და ავტომატურად ახლდება 21-დღიან ფანჯარაში. proxy TLS-ს ასრულებს და შენს აპლიკაციას ჩვეულებრივ HTTP-ს გადასცემს, ვიზიტორის რეალური მისამართით X-Forwarded-For-ში. მიუთითე დომენი სერვერზე და დაამატე SSL ამ კონფიგურაციას და გაცემის ჩავარდნის მიზეზებს აღწერს.

სერტიფიკატის შეცდომები და რას ნიშნავენ#

HTTPS-ის უმეტესი პრობლემა ბრაუზერის რამდენიმე შეცდომად ჩნდება. კოდები ბრაუზერებს შორის განსხვავდება; მიზეზები იგივეა.

ვადაგასული. ან საიტის განახლება ჩავარდა, ან ვიზიტორის მოწყობილობის საათია არასწორი. ტელეფონი ან კომპიუტერი, რომელსაც წლების წინანდელი თარიღი უდგას, ინტერნეტის ყველა სერტიფიკატს ერთბაშად უარყოფს, ეს არის ნიშანი: თუ ყველა საიტი ტყდება, შეამოწმე საათი.

არასწორი სახელი. სერტიფიკატი example.com-ს ფარავს, მაგრამ ვიზიტორი www.example.com-ით მოვიდა, ან ახალი ქვედომენი სერვერზე მიუთითეს მისთვის სერტიფიკატის გაცემამდე. სერტიფიკატი მხოლოდ მასში ჩამოთვლილი სახელებისთვის მოქმედებს.

უცნობი გამცემი. სერვერი შუალედურ სერტიფიკატს არ აგზავნის, ან სერტიფიკატი თვითხელმოწერილია. შეამოწმე მანქანიდან, რომელსაც საიტზე არასოდეს შეუსვლია, ან გამოიყენე ზემოთ მოცემული openssl ბრძანება, რომელიც სერვერის რეალურად გაგზავნილ ჯაჭვს აჩვენებს.

არაუსაფრთხო, მოქმედი სერტიფიკატით. Mixed content: გვერდი HTTPS-ზეა, მაგრამ სკრიპტს, სტილის ფაილს ან სურათს http://-ით ტვირთავს. ბრაუზერები აქტიურ შინაარსს სრულად ბლოკავენ და გვერდი ნახევრად იხატება. ბრაუზერის კონსოლი ზუსტ URL-ს ასახელებს.

`ERR_TOO_MANY_REDIRECTS`. ჩვეულებრივ აპლიკაცია TLS-ის დამასრულებელი proxy-ს უკან, რომელიც საკუთარ პორტზე ჩვეულებრივ HTTP-ს ხედავს და HTTPS-ზე გადამისამართებას აგრძელებს. აპლიკაციამ სანაცვლოდ proxy-ის X-Forwarded-Proto header-ს უნდა ენდოს. რას აკეთებს reverse proxy ამის მიზეზს განმარტავს.

იმის შესამოწმებლად, როგორ იქცევა საიტი გარედან, ორი ბრძანება პასუხობს უმეტეს კითხვას:

# Does HTTP redirect to HTTPS, and to which host?$ curl -sI http://example.com | grep -iE "^(HTTP|location)"# Is HSTS set, and for how long?$ curl -sI https://example.com | grep -i strict-transport-security

FAQ#

HTTPS იგივეა, რაც SSL?

ყოველდღიურ მეტყველებაში - დიახ. ტექნიკურად HTTPS არის HTTP, რომელიც TLS-ით გადაიცემა, TLS კი SSL-ს 1999 წელს ჩაენაცვლა. SSL-ის ყველა ვერსია ახლა არასაიმედოდ გაუქმებულია, მაგრამ ძველი სახელი დარჩა, ამიტომ სერტიფიკატები კვლავ „SSL სერტიფიკატებად" იყიდება. ისინი TLS 1.2-თან და 1.3-თან გამოიყენება.

ანელებს HTTPS საიტს?

თანამედროვე აპარატურაზე გაზომვადად არა. handshake ახალ კავშირზე ერთ წრიულ მოგზაურობას ამატებს, განახლებულზე - ნაკლებს, თავად დაშიფვრა კი პროცესორის სპეციალურ ინსტრუქციებზე სრულდება. პრაქტიკაში HTTPS საიტები ხშირად უფრო სწრაფია, რადგან ბრაუზერები HTTP/2-სა და HTTP/3-ს მხოლოდ TLS-ზე იყენებენ.

ხედავს ჩემი ინტერნეტ-პროვაიდერი, რომელ საიტებს ვსტუმრობ HTTPS-ით?

ის ხედავს IP მისამართებს, რომლებსაც უკავშირდები, და უმეტეს შემთხვევაში ჰოსტის სახელსაც - შენი DNS მოთხოვნებიდან და handshake-ში SNI ველიდან. ვერ ხედავს, რომელი გვერდები გახსენი, რას ეძებდი საიტზე ან რას აკრიფე. დაშიფრული DNS და Encrypted Client Hello ამას კიდევ უფრო ავიწროებს იქ, სადაც ორივე მხარე მხარს უჭერს.

რამდენ ხანს მოქმედებს სერტიფიკატი?

Let's Encrypt-ის უფასო სერტიფიკატები 90 დღე მოქმედებს და ავტომატურად ახლდება. ნებისმიერი საჯაროდ სანდო სერტიფიკატის ინდუსტრიული მაქსიმუმი არაერთხელ შემცირდა და მომდევნო წლებშიც კლებად არის დაგეგმილი, ამიტომ ყოველწლიური ხელით განახლება ყველგან ქრება.

საკმარისია თვითხელმოწერილი სერტიფიკატი?

კერძო სატესტო სერვერზე დაშიფვრისთვის - დიახ. საჯარო საიტისთვის - არა: არც ერთი ბრაუზერი არ ენდობა მას, ამიტომ ყველა ვიზიტორს სრულეკრანიანი გაფრთხილება ხვდება, ხალხისთვის გაფრთხილებებზე გადასვლის სწავლება კი ვინაობის შემოწმებას აუქმებს, რაც HTTPS-ს მუშაობის საშუალებას აძლევს.

მჭირდება HTTPS სათამაშო სერვერისთვის?

თავად თამაშის ტრაფიკისთვის არა - Minecraft, Valheim და უმეტესი თამაში საკუთარ პროტოკოლებს საკუთარ პორტებზე იყენებს და არა HTTP-ს. ის გჭირდება ყველაფერისთვის, რაც თამაშის გარშემო ვებისკენ არის მიმართული: ვებსაიტი, რუკის დამთვალიერებელი, შემოწირულობის გვერდი ან პანელი.