Როგორ მუშაობს SSL და HTTPS ჰემბლინგში

ონლაინ კაზინოები ამუშავებენ გადახდებს, KYC დოკუმენტებს, სესიებისა და დასკვნების ისტორიას. ნებისმიერი გაჟონვა - ჯარიმები, შეძენის დაბლოკვა, რეპუტაციის დაზიანება. SSL/TLS და HTTPS არის ბრაუზერის სერვერის არხის ძირითადი „ჯავშანი“, ხოლო სექსუალურ ინფრასტრუქტურებში ასევე არის „CDN/WAF“ და mTLS შიდა API (PAM, RGS, გადახდის ვებჰუკები). ჩვენ გავაანალიზებთ რა არის ქუდის ქვეშ და როგორ უნდა შეადგინოთ ყველაფერი ზუსტად ჰემბლინგისთვის.

ბაზა: რა განსხვავებაა SSL, TLS და HTTPS

TLS არის ტრანსპორტის დაშიფვრის პროტოკოლი (მოძველებული SSL- ის მემკვიდრე).

HTTPS არის ჩვეულებრივი HTTP, რომელიც ტრანსპორტირდება TLS- ით.

მიზნები: კონფიდენციალურობა (დაშიფვრა), მთლიანობა (MAC/AEAD) და სერვერის ნამდვილობა (სერთიფიკატი).

რა ხდება TLS ხელჩანთაში (ძალიან მოკლედ)

1. კლიენტი „მისასალმებელია“: ალგორითმები, SNI (რომელი დომენი), ALPN (HTTP/1. 1 ან HTTP/2/3).

2. სერვერი პასუხისმგებელია სერთიფიკატით + ნდობის ჯაჭვით და დაშიფვრის პარამეტრებით.

3. მხარეები შეთანხმდნენ კლავიშებზე (ECDHE - Perfect Forward Secrecy).

4. სერტიფიკატის შემოწმება (ჯაჭვი, ვადა, ამოღება/არა, სახელი ემთხვევა).

5. დაშიფრული არხი მზად არის; ჩვეულებრივი HTTP მიდის შემდეგ - უკვე TLS- ის შიგნით.

ოპტიმიზაცია: Resumption/Session Tickets, 0-RTT TLS 1-ში. 3 (დაზოგავს RTT- ს, მაგრამ მოითხოვს სიფრთხილეს მოთხოვნის გამეორების გამო).

სერთიფიკატები და PKI (რაც ოპერატორებისთვის მნიშვნელოვანია)

ტიპები: DV (დომენი), OV (ორგანიზაცია), EV (გაფართოებული შემოწმება). კაზინოსთვის, ჩვეულებრივ, OV/EV საზოგადოებრივ დომენებზე.

Wildcard '.example. com 'და/ან SAN რამდენიმე დომენისთვის.

Certificate Transparence: პუბლიკაცია CT- ში, ჩვენ ვაკვირდებით „უცხო“ ნომრებს ჩვენს ბრენდზე.

OCSP stapling: სერვერი „აყენებს“ მიმოხილვის სტატუსს, აჩქარებს შემოწმებას.

💡 შიდა სერვისები (admink, webhuks, მომსახურება-tu-service) - უფრო ხშირად mTLS- ზე პირადი CA- სგან: სერვერი და კლიენტი წარმოადგენენ ერთმანეთის სერთიფიკატებს.

HTTPS რეალურ კასკადში iGaming


მოთამაშის ბრაუზერი - CDN/WAF (TLS), Origin/Frontend
↓ (TLS)
API Gateway / PAM
↓ (mTLS)
RGS / Payments

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

რა არის დაშიფვრა და სად არის ეს მნიშვნელოვანი

ანაბრები/დასკვნები: პირადი ანგარიში, შევსება, Visa Direct/Mastercard Send სტატუსები - მკაცრად HTTPS.

KYC: დოკუმენტების დატვირთვა და საფორტეპიანო ჩეთები - მხოლოდ HTTPS + უსაფრთხო ქუქი-ფაილები.

თამაშის/ბალანსის ისტორია: პირადი მონაცემები, სავალდებულო დაშიფვრა.

WebSockets: ჩვენ ვიყენებთ wss ://( TLS სოკეტებისთვის) ლაივ კაზინოში/ჩატებში.

Bebhuks PSP: მიიღეთ HTTPS, ხშირად mTLS + - ით, სხეულის ხელმოწერით.

TLS კონფიგურაციის „ჰიგიენა“

ვერსიები: ჩართეთ TLS 1. 2/1. 3, გამორთეთ SSLv3/TLS 1. 0/1. 1.

შიფრები: ECDHE + AES-GCM/ChaCha20-Poly1305 (PFS).

HSTS: `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 'mixed შინაარსის აღმოფხვრის შემდეგ.

Security headers:

`Content-Security-Policy` (с `frame-ancestors` вместо `X-Frame-Options`)
`X-Content-Type-Options: nosniff`
'Referrer-Policy: no-referrer-when-downgrade' (ან უფრო მკაცრი)
კუკი: 'Secure; HttpOnly; SameSite = Lax/Strict 'სესიებისთვის.
აკრძალვა mixed შინაარსი: HTTPS გვერდებზე HTTPS შინაარსი არ არის.
გასაღებები: RSA-2048/3072 ან EC-P256/P384; შენახვა HSM/KMS- ში, პოლიტიკის როტაცია.

ხშირი არქიტექტურული გაფართოება

mTLS: admins, დამხმარე API, გადახდის ვებჰუკები, CDN-origin ნაერთები.

SNI/ALPN: დანაზოგი IP და განახლება HTTP/2/3.

Pinning: არა მკაცრი HPKP (მოძველებული), არამედ CT და pin სიების მონიტორინგი მობილური მომხმარებლების/SDK დონეზე.

DDoS ფენები: WAF/CDN TLS ტერმინალით + L7 დაცვა, მაგრამ გაიმეორეთ დაშიფვრა და „CDN- სთვის“.

მონიტორინგი და ოპერაცია

ავტო წარმოება (ASME/ავტომატიზაცია), ალერტები გასვლამდე 30/14/7/1 დღით ადრე.

კონფიგურაციის სკანირება გამოშვების შემდეგ; ტესტები TLS Misconfig- ზე.

მეტრიკა: ხელით დაჭერის შეცდომები, ვერსია/ALPN, sharHTP/2/3, ლატენტობა.

CT მონიტორინგი: თქვენი ბრენდის საეჭვო სერთიფიკატების შესახებ შეტყობინებები.

Logs: downgrade მცდელობები, ადიდებული 'cipher _ mismatch', 'bad _ record _ mac'.

DR/BCP: სათადარიგო სერთიფიკატები, revoke/replace/rotate პროცედურები.

ინციდენტები და რეაქცია (runbook)

1. საკვანძო კომპრომისის ეჭვი არის დაუყოვნებელი გადახრა, ახლის გამოშვება, როტაცია ყველა ბალანსზე/ინგრედიენტზე.

2. Mixed შინაარსის ბლოკი არის ბლოკი CI/CD + SAST/ლინტერების მოხსენებებში.

3. გადაშენებული სერთიფიკატი - გადაუდებელი საკითხი + რეტროსპექტივა (რატომ არ მუშაობდა მონიტორინგი).

4. ფიშინგის დომენები - CT-Alert - საჩივარი SA/ბრაუზერის მოვაჭრეებში, მოთამაშეთა კომუნიკაცია.

ტიპიური ჰემბლინგის შეცდომები

TLS მთავრდება CDN- ში - CDN - origin დაშიფვრა არ არსებობს.

არ არსებობს HSTS ან ჩართულია mixed შინაარსის აღმოფხვრის გარეშე (საიტი იშლება).

სესიის ქუქი-ფაილები 'SameSite '/' Only' გარეშე.

Admink ხელმისაწვდომია საჯარო დომენებიდან DV სერთიფიკატით mTLS და IP-allow სიის ნაცვლად.

არ არსებობს CT მონიტორინგი: თავდამსხმელი აწარმოებს ანალოგიურ დომენს - ფეხბურთელები ტარდება.

შიდა კავშირები მომსახურებებს შორის არ არის დაშიფრული.

მინი ჰაიდი სერთიფიკატების არჩევისთვის

საჯარო დომენები (ბრენდი): OV/EV (+ SAN/Wildcard არქიტექტურაში).

ძრავის არხები (PSP ვებჰუკი, admin-API): პირადი CA + mTLS.

ცალკეული სერთიფიკატები ადმინისტრაციული და საზოგადოებრივი ფრონტისთვის (სხვადასხვა გასაღებები, სხვადასხვა პოლიტიკა).

ცენტრალიზებული ავტომატიზაცია (ACME) და ერთიანი nginx/Envoy/Ingress შაბლონები.

ოპერატორის ჩეკების სია (მოკლედ)

კონფიგურაცია: TLS 1. 2/1. 3, ECDHE+AES-GCM/ChaCha, OCSP stapling, HSTS preload, CSP, Secure/HttpOnly/SameSite, запрет mixed content.

ინფრა: TLS origin- მდე, mTLS შიდა/კრიტიკულ API- ზე, გასაღებები HSM/KMS- ში, CT მონიტორინგში.

პროცესები: ავტო დაბადება, ალერტები, პერიმეტრის პენტესტი, runbook revoke/rotate, შემოწმება თითოეული გამოშვების შემდეგ.

დაშვების პოლიტიკა: ცალკეულ დომენზე Admink, IP-allow-list, 2FA, როლების დელიმიტაცია.

მოთამაშის ჩეკის სია

მისამართის ზოლში https ://და „საკეტი“ შეცდომების გარეშე.

არ შეიტანოთ KUS/გადახდის მონაცემები, თუ ბრაუზერი ფიცს დებს სერთიფიკატს ან „შერეულ შინაარსს“.

შეამოწმეთ დომენი ასოზე; ნუ დააჭერთ „კაზინოს“ წერილებიდან - ჩამოდი სანიშნეებიდან.

FAQ (მოკლედ)

საჭიროა EV სერტიფიკატი? არ არის სავალდებულო. მთავარია TLS- ის სწორი კონფიგურაცია და პროცესები. EV- ს შეუძლია გაზარდოს ნდობა B2B- ში.

თუ PSP იღებს ბარათის მონაცემებს, შეგიძლიათ HTTPS- ის გარეშე? არა. რჩება ლოგინები, ნიშნები, KYC, ჩეთები, ისტორია - ეს ყველაფერი პერსონალური მონაცემებია.

0-RTT в TLS 1. 3 უსაფრთხო? Idempotent GET- ისთვის - დიახ; ჰემბლინგის POST- ისთვის უმჯობესია გამორთვა ან შეზღუდვა.

ლიცენზირებული ოპერატორისთვის HTTPS არ არის ბროშურა, არამედ სისტემა: ძლიერი TLS პროფილი, HSTS და CSP, უსაფრთხო ქუქი-ფაილები, დაშიფვრა „CDN- სთვის“, mTLS შიდა არხებზე და გასაღების დისციპლინაში. ეს იცავს გადახდებს და KYC მონაცემებს, აჩქარებს PSP/ბანკების ონბორდინგს და ზრდის მოთამაშეთა ნდობას - ანუ ის პირდაპირ გავლენას ახდენს შემოსავალსა და ლიცენზიაზე.