Bài giảng An toàn an ninh mạng - Bài 8: An toàn dịch vụ Web HTTPS - Bùi Trọng Tùng

BÀI 7.
AN TOÀN DỊCH VỤ WEB
HTTPS
Bùi Trọng Tùng,
Viện Công nghệ thông tin và Truyền thông,
Đại học Bách khoa Hà Nội
 1
1. GIAO THỨC SSL/TLS
Bùi Trọng Tùng,
Viện Công nghệ thông tin và Truyền thông,
Đại học Bách khoa Hà Nội
 2
 1
 SSL/TLS là gì?
• Sercure Socket Layer/Transport 
 Layer Security
• Nằm giữa các giao thức tầng 
 giao vận và tầng ứng dụng
• Cung cấp các cơ chế mã mật và 
 xác thực cho dữ liệu trao đổi 
 giữa các ứng dụng
• Các phiên bản: SSL 1.0, SSL 
 2.0, SSL 3.0, TLS 1.0 (phát triển 
 từ SSL 3.0)
 SSL/TLS là gì?
 • Gồm 2 giao thức con
 • Giao thức bắt tay(handshake protocol): thiết lập kết nối 
 SSL/TLS
 Sử dụng các phương pháp mật mã khóa công khai để các bên 
 trao đổi khóa bí mật
 • Giao thức bảo vệ dữ liệu(record protocol)
 Sử dụng khóa bí mật đã trao đổi ở giao thức bắt tay để bảo vệ dữ 
 liệu truyền giữa các bên
 2
Giao thức bắt tay
 ClientHello
 ServerHello, 
 [Chứng thư số]S
 [ServerKeyExchange]
 [Yêu cầu chứng thư số]S
 ServerHelloDone
 [Chứng thư số]C
 C [ClientKeyExchange] S
 [Xác thực chứng thư]
 Thỏa thuận thuật toán mật mã
 Hoàn thành
 Thỏa thuận thuật toán mật mã
 Hoàn thành
Client Hello
 ClientHello
 Thông tin giao thức mà client hỗ trợ:
 • Phiên bản giao thức SSL/TLS
 • Các thuật toán mật mã
 C S
 3
Server Hello
 Giá trị ngẫu nhiên
 C, Versionc, suitec, Nc
 ServerHello
 • Phiên bản giao thức SSL/TLS cao 
 nhất mà 2 bên cùng hỗ trợ
 C • Thuật toán mã hóa mạng nhất mà S
 2 bên cùng hỗ trợ
ServerKeyExchange
 Giá trị ngẫu nhiên
 C, Versionc, suitec, Nc
 Versions, suites, Ns,
 ServerKeyExchange
 C Thuật toán trao đổi khóa, thông S
 tin sinh khóa và/hoặc chứng thư 
 số của server (tùy thuộc thuật 
 toán trao đổi khóa)
 4
ServerKeyExchange
ClientKeyExchange
 C, Versionc, suitec, Nc
 Versions, suites, Ns,
 ClientKeyExchange
 “ServerHelloDone”
 C ClientKeyExchange S
 Thuật toán trao đổi khóa, thông tin 
 sinh khóa và/hoặc chứng thư số của 
 client (tùy thuộc thuật toán trao đổi 
 khóa)
 5
ClientKeyExchange
Hoàn tất giao thức bắt tay
 C, Versionc, suitec, Nc
 Versions, suites, Ns,
 ServerKeyExchange,
 “ServerHelloDone”
 C ClientKeyExchange S
 Client và server chia sẻ thành công các thông tin sinh khóa
 và sử dụng các thông tin này để tạo khóa chính.
 Khóa chính được sử dụng để trao đổi các khóa phiên
 6
Các bộ thuật toán mã hóa trên TLS 1.0
Bảo vệ dữ liệu trên kênh SSL/TLS
 7
Một số cải tiến trên TLS 1.0
• Thuật toán sinh khóa an toàn hơn: sử dụng 2 hàm
 Mở rộng giá trị bí mật
 Hàm giả ngẫu nhiên kết hợp 2 hàm băm MD5 và SHA-1 để sinh 
 thông tin tạo khóa
• Sử dụng các hàm HMAC thay thế cho MAC
Hàm mở rộng giá trị bí mật
 8
Hàm giả ngẫu nhiên PRF
Sinh giá trị master-secret
 9
Sinh thông tin tạo khóa
Hàm HMAC trong TLS 3.0
 10
 2. GIAO THỨC HTTPS
 Bùi Trọng Tùng,
 Viện Công nghệ thông tin và Truyền thông,
 Đại học Bách khoa Hà Nội
 21
Giới thiệu chung về HTTPS
• Hạn chế của HTTP:
 Không có cơ chế để người dùng kiểm tra tính tin cậy của Web 
 server lỗ hổng để kẻ tấn công giả mạo dịch vụ hoặc chèn mã 
 độc vào trang web HTML
 Không có cơ chế mã mật lỗ hổng để kẻ tấn công nghe lén đánh 
 cắp thông tin nhạy cảm
• Secure HTTP: Kết hợp HTTP và SSL/TLS:
 Xác thực
 Bảo mật
 22
 11
Thiết lập liên kết SSL/TLS
 Chứng thư số
 browser server
 client-hello
 cert
Xác minh 
 server-hello + server-cert (chứa khóa KUS) Private 
server-
cert key
 Thỏa thuận thông số trao đổi khóa
Sinh 
 Trao đổi khóa: E(K , K )
khóa bí US S
 KS
mật KS
 Thiết lập xong kết nối TLS
 Thông điệp HTTP được mã hóa với KS
 23
Chứng thư số - Ví dụ
 24
 12
HTTP trên trình duyệt Web
 Truy cập dịch vụ Web với HTTP
 Khi click vào liên kết...
 25
HTTPS trên trình duyệt Web
 Truy cập Web với HTTPS
 - Toàn bộ nội dung website (bao gồm 
 hình ảnh, CSS, Flash, scripts...) đã 
 được trình duyệt thẩm tra tính toàn vẹn 
 và nguồn gốc tin cậy.
 - Mọi thông tin trao đổi giữa trình duyệt 
 và BIDV được giữ bí mật.
 26
 13
Tại sao HTTPS an toàn?
• Chặn bắt dữ liệu
• Chèn mã độc vào nội dung website khi truyền từ server 
 tới trình duyệt web
• Tấn công DNS cache poisioning
 Client truy cập vào Web server của kẻ tấn công
• Tấn công DHCP Spoofing
 Client truy cập vào Web server của kẻ tấn công
• Tấn công định tuyến để chuyển hướng truy cập
• Tấn công man-in-the-middle
• Tấn công phát lại
 27
Quá trình xác minh chứng thư số
• Bước 1: Trình duyệt so sánh tên miền trong chứng thư số 
 (Subject CN)và tên miền trên địa chỉ URL
 Tên tường minh: dnsimple.com, hoặc
 Tên đại diện: *.dnsimple.com, dn*.dnsimple.com
• Bước 2: Trình duyệt kiểm tra thời gian hiệu lực của chứng 
 thư số
• Bước 3: Trình duyệt kiểm tra chứng thư số gốc của CA 
 chứng thực cho server
 Để xem các chứng thư số gốc trên trình duyệt Firefox
 Options Advanced View Certificates Authorities
• Bước 4: Trình duyệt sử dụng chứng thư số gốc của CA 
 để thẩm tra chữ ký số trên chứng thư của server
 28
 14
Chứng thư số gốc
• Được tích hợp sẵn trên trình duyệt
 29
Chuỗi chứng thực
 30
 15
Chuỗi chứng thực
 Certificate
 “I’m because I say so!”
 Certificate
 “I’m because says so”
 Certificate
 “I’m because says so”
 Chuỗi xác thực từ chối chứng thư số nếu có bất kỳ 
 bước nào cho kết quả xác thực thất bại
 31
Không tìm thấy chứng thư số gốc
 Còn an toàn 
 không khi người 
 dùng chấp nhận 
 cảnh báo?
 32
 16
 Tấn công vào HTTPS
 • Tấn công sslstrip: lợi dụng lỗ hổng chuyển từ truy cập 
 qua HTTP sang truy cập qua HTTPS (như thế nào?)
 Truy cập dịch vụ Web với HTTP
 Khi click vào liên kết...
 33
 Tấn công sslstrip
 HTTP SSL
 web
 attacker server
 Nội dung trả về từ Nội dung thay thế bởi 
 web server attacker
Location: https://... Location:  (redirect)
• Các trang có lỗ hổng này: ebay.com, rất nhiều ngân hàng lớn 
 ở Việt Nam (Agribank, Vietinbank, Vietcombank, BiDV, ACB 
 bank...)
 34
 17
Tấn công sslstrip
• Thậm chí, trên các website hỗ trợ đầy đủ HTTPS, nhưng 
 có thể lợi dụng người dùng không cập nhật trình duyệt 
 phiên bản mới
• Thay fav icon
• Xóa cookie bằng cách chèn header “set-cookie” người 
 dùng bắt buộc đăng nhập lại
 Phần lớn không phát hiện HTTPS HTTP
 35
Phòng chống: Strict Transport Security 
(HSTS)
 6
 Strict-Transport-Security: max-age=31 10 ; includeSubDomains web
 (bỏ qua nếu liên kết không phải là HTTPS) server
• Một trường trên tiêu đề của HTTPS Response, yêu cầu 
 trình duyệt luôn kết nối với máy chủ qua HTTPS
• HSTS chỉ được chấp nhận trên các liên kết HTTPS
• Max-age: thời gian duy trì
• Kiểm tra danh sách các website hỗ trợ HSTS:
 chrome://net-internals/#hsts
 %APPDATA%\Mozilla\Firefox\Profiles\...\SiteSecurityServiceState.t
 xt
 36
 18
 CSP: upgrade-insecure-requests
 • Các trang thường trộn lẫn các URL của tài nguyên với 
 HTTPS
 Ví dụ: 
 • Thêm vào tiêu đề trong HTTP Response
 Content-Security-Policy: upgrade-insecure-requests
 • Trình duyệt tự động chuyển các liên kết sử dụng HTTP 
 sang HTTPS
 • Không áp dụng với thẻ 
 Luôn sử dụng URL tương đối: 37
 Tấn công vào HTTPS
 • Giao thức truy cập là HTTPS nhưng nội dung website không 
 được chứng thực đầy đủ
 • Ví dụ:
 • Nguy cơ: Kẻ tấn công thay thế những nội dung này
 • Cảnh báo trên trình duyệt 
IE7: Chrome(Các phiên bản cũ):
 • Chính sách của Chrome: chặn CSS, mã Javascript, thẻ 
 38
 19
 Tấn công lợi dụng website không được 
 chứng thực đầy đủ-Ví dụ
 39
 Tấn công vào HTTPS
 • Sử dụng CA giả mạo để phát hành chứng thư giả mạo
 • Người dùng sử dụng phiên bản trình duyệt không an toàn
 chứng thư gốc bị thay thế
GET https://bank.com BadguyCert BankCert
 attacker bank
 ClientHello ClientHello
 ServerCert (rogue) ServerCert (Bank)
 (cert for Bank by a invalid CA)
 SSL key exchange SSL key exchange
 k1 k1 k2 k2
 HTTP data enc with k1 HTTP data enc with k2
 40
 20
Phát hành chứng thư số sai cách
• 2011: Comodo and DigiNotar CAs bị tấn công, phát hành 
 chứng thư số cho các tên miền của Gmail, Yahoo! Mail, 
• 2013: TurkTrust phát hành chứng thư số cho gmail.com 
 (phát hiện nhờ cơ chế Dynamic HTTP public-key pinning)
• 2014: Indian NIC phát hành chứng thư số cho các tên 
 miền của Google
• 2015: MCS phát hành chứng thư số cho các tên miền 
 của Google
⇒ trình duyệt không phát cảnh báo khi kẻ tấn công thay 
thế chứng thư số
 41
Phòng chống chứng thư số giả mạo
• Dynamic HTTP public-key pinning:
 TOFU(Trust on First Use):
 Trường Public-Key-Pins trong tiêu đề của HTTP Response chỉ ra CA đã 
 cấp phát chứng thư số cho website
 Nếu các phiên tiếp theo, sử dụng chứng thư được chứng thực bởi CA 
 khác từ chối
• Giao thức “Certificate Transparency” cho phép CA công 
 bố toàn bộ bản ghi nhật ký (log) về các chứng thư đã phát 
 hành
• Giao thức OCSP (Online Certificate Status Protocol)
 42
 21
 HPKP – Ví dụ
Public-Key-Pins: max-age=2592000;
 pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
 pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";
 report-uri="https://example.net/pkp-report"
• chrome://net-internals/#hsts
• https://dxr.mozilla.org/mozilla-
 central/source/security/manager/tools/PreloadedHPKPins.json
 43
 Tấn công phishing
 • Homograph attack: Lợi dụng hình dáng giống nhau của 
 một số ký tự. Ví dụ: vvesternbank, paypai, paypail, 
 paypa1...
 • Semantic attack: lợi dụng các trình duyệt cũ không phân 
 biệt các dấu đặc biệt trên tên miền. Ví dụ: Kẻ tấn công có 
 thể mua tên miền badguy.cn và sử dụng tên miền con
 www.pnc.com/webapp/homepage.var.cn
 • Phòng chống: sử dụng chứng thư hỗ trợ chứng thực mở
 rộng (Extended validation certificate)
 44
 22
Semantic attack (ví dụ)
 45
Tấn công phishing (tiếp)
• Picture-in-picture attack: dựng một frame chứa cửa sổ 
 giao diện của một website đã được chứng thực lợi 
 dụng người dùng bất cẩn không quan sát khi duyệt web
 46
 23
Bài giảng sử dụng một số hình vẽ và ví dụ từ các bài 
giảng:
• Computer and Network Security, Stanford University
• Computer Security, Berkeley University
 47
 24