Web Security Scanning Wiki
Brought to you by:
lequocnhatdong
Menu
▾
▴
Home
Phát triển hệ thống Webscan
Skipfish Web App được xây dựng theo mô hình SaaS (Software as a Service) sử dụng công nghệ điện toán đám mây (cloud computing) vào lĩnh vực phát hiện lỗ hổng web. Skipfish Web App là hệ thống phần mềm cho phép quyét định kỳ các ứng dụng trên cổng HTTP (port 80) của các máy chủ web nhằm phát hiện ra các nguy cơ an ninh, các lỗ hổng bảo mật và các lỗi có thể xẩy ra đối với ứng dụng web của bạn như các lỗi SQL Injection, XSS, Blind Injection... để cảnh báo đến bộ phận an ninh hệ thống của Tổ chức để có thể triển khai những biện pháp phòng chống hợp lý.
Để tiến hành kiểm tra lỗ hổng website, người sử dụng không cần phải cài đặt bất kỳ phần mềm nào trên máy tính của mình. Người dùng chỉ cần truy cập website http://hsct.com.vn để thực hiện quét (trang web này đã được triển khai ứng dụng webscan). Hệ thống Web Scan này sẽ tương tác với website của người dùng để quét và thông báo lại kết quả quét tới họ.
Project Admins:
Discussion
Dưới đây là hình ảnh giao diện người dùng mặc định của Webscan v1.0 với những chức năng cơ bản.
Kết quả thử nghiệm hệ thổng kiểm định website sau khi crawl từ một website. Đây sẽ là một trong nhiều module mà mình sẽ sử dụng làm report cho sản phẩm dự thi MHST 2012 sắp tới.
Mới lập trình xong phần Scanning cho hệ thống Webscan. Tiến hành kiểm tra một số website tầm trung và đã có một bản báo cáo thống kê một cách chi tiết. Phần tạo ra hàng đợi Queue cho các website có vẻ tạm ổn. Tuy nhiên, do việc crawl và scan cho website mất khá nhiều thời gian, nên mình tạm thời quy định thời gian crawl và scan xuống còn 30 phút đến 1 tiếng để thuận lợi cho việc kiểm định kết quả quét. Để làm nên một hệ thống quét có trật tự và hiệu quả, ngoài việc lập trình web (PHP+HTML), công đoạn lập trình Shell (Linux) mất nhiều thời gian và chất xám nhất, nhiều khi còn phải làm lại từ đầu do chỉ duy nhất 1 câu lệnh Shell sai giữa chừng. Nhiệm vụ tiếp theo sẽ là công đoạn chứng thực chủ sở hữu website (web master), tất nhiên là vẫn dùng ngôn ngũ lập trình Shell.
Tiếp bước phiên bản webscan trên nền tảng Cloud Computing. Hôm nay mình vừa đã lập trình xong ứng dụng xác thực quyền sở hữu website. Đúng như theo dự đoán, module này sử dụng 70% Shell Script nhúng, và cũng tốn khá nhiều thời gian và công sức để làm nên Core Module. Trông giao diện có vẻ khá giống với bên BKAV, nhưng chắc chắn là Core hệ thống sẽ khác rất nhiều. Module xác thực quyền sở hữu Website này sẽ được tích hợp vào hệ thống chính để chứng minh quyền quản trị trang web của người có nhu cầu thuê dịch vụ kiểm định lỗ hỏng website.
Để tăng thêm năng lực cho hệ thống webscan, đồng thời khẳng định khả năng cạnh tranh trong cuộc thi MHST 2012, mình viết thêm một ứng dụng tích hợp thêm vào hệ thống webscan - SSL Server Test trên nền tảng Web sử dụng OpenSSL làm "mainboard". Hệ thống SSL Server Test này sẽ phân tích khá sâu sắc về cấu hình máy chủ SSL trên Internet và đưa ra số liệu thông tin cụ thể cũng như thang điểm đánh giá về SSL/TLS của máy chủ cần quét. Hình minh họa dưới đây mô tả một phần nhỏ của bản report SSL, sắp tới sẽ nâng cấp rất nhiều thông tin quan trọng cho bản Report đó, chẳng hạn như tính năng kiểm định độ dài của các key, lỗ hỏng BEAST attack,....
Chủ nhật, 16-09-2012, mình vừa cho ra đời một module mới phục vụ cho hệ thống SSL Server Analysis (sẽ phát triển sau này), đó là module kiểm tra Site đảm bảo kết nối thành công (200 OK) và xác nhận hỗ trợ giao thức HTTPS trước khi thực hiện phân tích các thông tin của SSL Server.
Vừa cho ra đời chương trình kiểm định virus trực tuyến, có tính năng phát hiện dấu hiệu bị virus từ tập tin người dùng tải lên, tương tự giả pháp Virus Total và Bkav Safezone. Sau khi người dùng tải tập tin lên máy chủ, hệ thống sẽ thực hiện các quy trình kiểm tra tập tin để đưa ra bản report cho người dùng.
Bản report sau khi hệ thống của mình quét các tập tin trong file nén rar. Thậm chí hệ thống này còn quét cả những macro virus của file word (.doc, docx)
Dưới đây là project lập trình và phát triển dịch vụ phân tích cấu hình của máy chủ Web sử dụng giao thức SSL/TLS khi đã publish trên Internet. Dịch vụ này sẽ phân tích và đưa ra bản report về thông tin máy chủ SSL, CA của tổ chức, Issuer, chữ kí số có đáng tin cậy hay không, độ dài của các key dùng để mã hóa/giải mã..., để người dùng quyết định trước khi thực hiện giao dịch thanh toán từ website đó. Điểm đặc biệt của hệ thống này là khả năng nhận dạng tấn công BEAST attack và CRIME attack vốn là 2 kĩ thuật tấn công được khai thác từ client.
Phát triển một module mới về kiểm tra các Protocol của SSL/TLS được tích hợp vào hệ thống SSL Analysis. Module này sẽ kiểm tra những website nào được hỗ trợ bởi SSL/TLS version nào, và phát hiện ra những website sử dụng giao thức SSL ver2.0 vốn đã bị quá nhiều lỗ hỏng bảo mật. Dưới đây là một phân tích về đối tượng là google.com, công nhận google này chịu đầu tư về mảng bảo mật thật, chơi luôn TLS 1.2, phiên bản TLS mà ít website nào ở Việt Nam hỗ trợ.
Đã lập trình và phát triển xong một tính năng mới cho hệ thống SSL Analysis - Nhận dạng tấn công Beast và Crime vốn là 2 kĩ thuật tấn công từ phía Client. Để kiểm tra độ chính xác của module này, mình đã tiến hành chọn một số đối tượng là các website có hỗ trợ HTTPS, nhất là các website giao dịch trực tuyến của các ngân hàng Việt Nam (ngoại trừ ngân hàng Đông Á). Kết quả là 70% các website trên đã bị lỗ hỏng SSL/TLS. Dưới đây là một phần report sau khi hệ thống phân tích được từ một cổng thanh toán trực tuyến nổi tiếng
Ở lần giới thiệu trước về dịch vụ quét virus trực tuyến trên nền tảng điện toán đám mây, anh Mẫn Thắng và một số đồng đạo giang hồ có góp ý là nên phát triển thêm tính năng quét tập tin ngay từ đường link download gốc, chứ không cần tải về máy rồi upload lên máy chủ xử lý. Mình thấy tính năng này rất khả thi với nhu cầu cơ bản về bảo mật thông tin hiện nay. Giả sử như người dùng click vào 1 link nào đó, thì nó sẽ tự download tập tin bị nhiễm virus về máy tính, lúc đó thì trở tay không kịp nếu như người dùng chưa cài đặt phần mềm diệt Virus cho máy tính. Tính năng này ít được phát triển ở một số dịch vụ quét virus trực tuyến nên với ý tưởng này sẽ bớt phần nào khả năng cạnh tranh. Dưới đây là link demo dịch vụ.
Link 1: Dịch vụ quét virus trực tuyến với tính năng download tập tin cần quét từ máy tính
http://hsct.com.vn/scanvirus/scanvirus.pl
Link 2: Dịch vụ quét virus trực tuyến với tính năng quét trực tiếp từ link gốc tải về
http://hsct.com.vn/scanvirus/scanlink.pl
P/S: Giao diện hoạt động tốt với Chome và Firefox.
Dưới đây là bản phân tích quy trình thiết kế của hệ thống Webscan & SSL Analysis. Hình dưới đây sẽ mô tả rõ những công đoạn khi lập trình nên hệ thống này, vốn là công việc không thể bỏ qua đối với một System Developer. Ngày nay, cụm từ System Developer dần trở nên phổ biến và mang tính chất quan trọng trong bất kì doanh nghiệp phát triển CNTT
Hệ thống phân tích và kiểm địch máy chủ SSL và Certificate vừa mới được nâng cấp. Giao diện dễ dùng hơn, hiệu suất hệ thống cao hơn, tính toán và phân tích chính xác hơn, quy trình phân tích và kiểm định đối tượng gắt gao hơn... Hi vọng phiên bản này sẽ là bước tiến lớn trong dự án Webscan, vốn là một dự án thuần về bảo mật thông tin (security).
Link: http://hsct.com.vn/ssllab/analysis.pl
P/S: Ứng dụng hoạt động tốt trên trình duyệt Chrome, Firefox
Hệ thống Webscan SSL/TLS (1 trong 5 dự án của mình) đã được nâng cấp thêm với tính năng phát hiện certificate giả mạo (Fake certificate). Hệ thống sẽ dùng khóa công khai từ certificate của nhà cung cấp từ danh sách tin tưởng để so với chữ ký số trên Certificate của đối tượng máy chủ cần phân tích để chắc chắn rằng không xảy ra việc giả mạo certificate của tổ chức này. Nếu thông tin trên certificate đối tượng máy chủ thay đổi hoặc khóa công khai không giải mã được chữ ký trên certificate thi tiến trình kiểm tra sẽ bị hệ thống webscan đặt tình trạng là Untrust và ngược lại nếu máy khách giải mã được và thông tin trong đó là chính xác thì tình trạng sẽ là Trusted (Not fake). Ngoài ra hệ thống này còn có tính năng xác minh domain đang liên lạc có trùng khớp với domain trong certificate không để ngăn cản tấn công Man in the middle.
Dưới đây là tính năng detect EV (Extended Validation), là tính năng cuối cùng được mình viết ra để tích hợp vào hệ thống SSL Analysis. Extended Validation (EV) là một hình thức xác minh đặc biệt của của các nhà cung cấp dịch vụ xác thực chứng chỉ số (Certificate Authority - CA). Mỗi CA có một tiêu chuẩn và quy trình xác minh riêng của họ, nhưng đều rất chặt chẽ và đều có một mục đích chung duy nhất là kiểm tra và đảm bảo tính chính xác, đáng tin cậy, đang hoạt động tốt của công ty đăng ký chứng chỉ số Extended Validation (EV).
Thật ra, tính năng EV này không hẳn là gia tăng bảo mật dữ liệu so với chứng chỉ cùng cấp (không có EV) mà gia tăng độ tin cậy của website người dùng về mặt pháp lý, cũng như thể hiện uy tín của CA xác thực website đó. Các chứng chỉ số EV sẽ không bao giờ được cấp cho những cá nhân hay tổ chức không có tư cách pháp nhân đầy đủ tại nước sở tại. Những công ty có tiểu sử không tốt, đang có những vấn đề về tài chính, thuế,... cũng sẽ không thuộc dạng được cấp chứng chỉ số EV. Tính năng EV này được cấp cho các tổ chức có thâm niên ít nhất 3 năm triển khai dịch vụ. Chính vì những nguyên nhân như trên mà chứng chỉ số EV luôn luôn đắt hơn, thời gian cấp lâu hơn (từ 2-3 tuần), và đương nhiên mức bảo hiểm tối đa từ CA (khi xảy ra sự cố mà nguyên nhân từ phía CA) cũng cao hơn so với một chứng chỉ số cùng loại nhưng không có EV.
Hình minh họa dưới đây sẽ xác định website (hỗ trợ HTTPS) của chủ sở hữu có sử dụng chứng chỉ số EV hay không. Cảm ơn anh Mẫn Thắng (sinh viên năm cuối Đại học CNTT TPHCM) đã giới thiệu cho mình dự án SSL Lab của tập đoàn bảo mật Qualysis, để mình có ý tưởng build lại hệ thống SSL Analysis trên nền tảng OpenSSL. Hy vọng anh sẽ có những chia sẻ tương tự như thế trong Home Page Facebook của anh, kể cả trang Keep Security in Mind.
Last edit: Le Quoc Nhat Dong 2012-10-16
Sản phẩm Webscan lần trước với phiên bản 1.2 đã được Ban tổ chức MHST 2012 chấm vào vòng chung kết, đó là một khởi đầu khá suông sẻ, mặc dù phiên bản đó chưa hoàn thiện và quá thô sơ, cũng may mà nhờ module SSL Analysis hỗ trợ tích hợp vào. Hiện nay, mình cho ra đời phiên bản Webscan 2.0 (big update) với các tính năng được thừa hưởng tinh hoa từ phiên bản 1.2 trước đó, nhưng hiệu suất cao hơn, report chi tiết hơn, giao diện web gần gũi hơn với người sử dụng, các lỗ hỏng website (sử dụng giao thức HTTP port 80) được thông báo chi tiết hơn. Hệ thống Webscan này sẽ liệt kê các lỗi mở port, lỗi cập nhật, các lỗi cấu hình web server, các lỗi injection (XSS/LDAP/SQL/X-path),... Với thế mạnh từ hệ thống Webscan với phiên bản 2.0 này, sẽ tạo một lợi thế rất lớn trong vòng chung kết sắp tới mà không cần sự hỗ trợ đắc lực từ hệ thống SSL Analysis (quét cổng 443) và Scan Virus Online, vừa đảm bảo đáp ứng cả 2 yêu cầu của cuộc thi là Cloud Computing và Security, vốn là 2 mảng CNTT phổ biến nhất hiện nay. Thông tin demo sẽ được mình tiết lộ sau.
Last edit: Le Quoc Nhat Dong 2012-10-20
Dưới đây là hình ảnh giao diện chính mặc định của Webscan phiên bản mới nhất (version 2.0). Không như phiên bản thô kệch lần trước mình nộp cho BTC (version 1.2), phiên bản này sẽ cải thiện nhiều hơn về mặt giao diện người dùng, bố cục giao diện sắp xếp gọn gàng ngăn nắp hơn, hiện đại hơn. Điều khác biệt rõ nhất của đợt Big Update này là sẽ có cấu trúc CSDL được tổ chức đàng hoàng chặt chẽ, tuy nhiên CSDL cụ thể nào ở đây (là MySQL, MSSQL, Oracle, DB2, PostgreSQL hay MongoDB,...) thì mình xin giữ bí mật đến phút cuối. Hy vọng mọi điều xảy ra với dự án được tốt đẹp và như mong đợi.
Lần trước các đồng đạo giang hồ hỏi mình làm sao mà module trong dự án SSL Analysis có thể phát hiện (detect) lỗ hỏng BEAST và CRIME, vốn là 2 lỗ hỏng nhắm vào giao thức bảo mật SSL/TLS. Mình cũng chia sẻ luôn, muốn detect được nguy cơ của hai cuộc tấn công thì website có hỗ trợ HTTPS sẽ được hệ thống SSL Analysis trải qua những quy trình kiểm định khác nhau, cụ thể là:
BEAST attack : Sẽ trải qua 4 tầng kiểm định:
Tầng 1: Server của đối tượng kiểm định có hỗ trợ giao thức TLS 1.1 và TLS 1.2 không (hoặc 1 trong 2 cái đó). Nếu có hỗ trợ thì kết quả miễn nhiễm với BEAST, còn nếu không hỗ trợ thì sẽ bước qua tầng 2.
Tầng 2: Server của đối tượng cần kiểm định hỗ trợ giao thức bảo mật SSL 2.0 hay SSL 3.0/TLS 1.0. Nếu hỗ trợ SSL 2.0 thì sẽ detect là nguy cơ bị tấn công BEAST (và vô số lỗ hỏng SSL/TLS khác) rồi đặt flag tình trạng báo động đỏ, nếu hỗ trợ SSL 3.0/TLS 1.0 thì sẽ bước qua tầng kiểm định thứ 3.
Tầng 3: Server của đối tượng cần kiểm định có hỗ trợ CBC-based cipher suite không, tức mã hóa khối - Block Cipher. Nếu không hỗ trợ CBC-based cipher suite thì kết quả miễn nhiễm BEAST, còn nếu có hỗ trợ thì sẽ bước qua tầng kiểm định thứ 4.
Tầng 4: Có thể server của đối tượng cần kiểm định sẽ có nhiều CBC cipher (DES3, AES,...) xen kẽ với non-CBC cipher (Stream Cipher như RC4 hoặc Block Cipher trong GCM hoặc CCM mode). Nếu hỗ trợ nhiều hơn 2 đối tượng non-CBC cipher thì kết quả miễn nhiễm BEAST, tuy nhiên miễn nhiễm ở tình trạng đề phòng (warning).
Mặc dù module detect CRIME attack cũng đã lập trình xong, cũng đã kiểm thử tính năng này với một số đối tượng website có hỗ trợ HTTPS với độ chính xác cao, nhưng có lẽ mình còn thiếu một số thông tin bí ấn về kĩ thuật tấn công mới này, cũng chẳng dám nói bừa. Mình sẽ post trong những bài viết sau, chắc ăn hơn nữa là tham gia hội thảo Tetcon 2013 (13-1-2013) để nghe anh Thái Dương chia sẻ về lỗ hỏng bá đạo này.
Theo như lời góp ý của anh Mẫn Thắng , vào thời điểm 28/10/2012, mình đã viết xong một module tính năng phát hiện rủi ro SSL Dos Attack. Đây là kiểu tấn công có liên quan đến request Renegotiation, và cũng là một trong nhiều kiểu tấn công DDoS khai thác cơ chế SSL handshake để làm quá tải tài nguyên và năng lực xử lý của server. Ở phiên bản SSL Analysis trước có module check Secure Renegotiation, và lần này mình sẽ phối hợp với module check Client-initiated Renegotiations (Song kiếm hợp bích) để tạo thành module SSL Dos Attack với 2 tầng kiểm định. Nếu một trong hai module đó detect được nguy cơ SSL Dos Attack (không hỗ trợ Secure Renegotiation, hoặc trạng thái Honored của module Client-initiated Renegotiations) thì sẽ liệt vào báo động cấp 1, còn nếu cả hai module cùng lúc phát hiện thì nguy cơ bị tấn công SSL Dos Attack lên mức Dangerous cấp độ 2. Đây là một trong những nỗ lực phát hiện nguy cơ khác thác cơ chế SSL handshake, còn nhiều ý tưởng khác mà mình từng ngày nghiên cứu thêm.
30/10/2012, mình đã viết xong một module mới tên là Hostname Validation. Module này có tính năng kiểm tra hostname của server (hoặc tên miền cần kiểm định) có trùng khớp với hostname trong Certificate không. Tính năng này sử dụng cơ chế so khớp thông minh được áp dụng cho sub-domain so sánh với hostname. Nếu hostname trong Certificate là một tên miền chính, trong khi đó hostname (hoặc tên miền) của server là một sub-domain thì module này vẫn nhận biết được. Trong phiên thử nghiệm thứ nhất, tên miền chính trong Certificate của một đối tượng cần kiểm định là *.zing.vn, mà sub-domain nhập vào là pay.zing.vn thì module sẽ báo là Matched (OK). Trong phiên thử nghiệm thứ hai, tên miền chính trong Certificate của một đối tượng khác là vcloud.optimum.vn, mà sub-domain nhập vào là cloud.optimum.vn (khác kí tự đầu tiên) thì module sẽ báo là Mismatch (Warning). Trong phiên thử nghiệm cuối cùng, mình sử dụng domain 4 cấp để thực hiện lại tương tự hai thử nghiệm trên (vd: abc.zxc.wer.com), module vẫn nhận biết tốt. Đây là tính năng không thể thiếu trong việc kiểm định giao thức SSL/TLS để tránh hiện tượng Redirect Domain, Alias Domain for Website, Content Delivery Network (CDN) without SSL/TLS, Domain Points To The Old IP Address. Những tên miền điển hình cho việc "Mismatch Hostname" là fb.com, gmail.com
01/11/2012, mình đã viết ra một module mới tên là TLS Session Tickets, là một trong những cơ chế quan trọng nhất dùng để cải thiện hiệu suất SSL bằng cách cải thiện độ trễ và thời gian tính toán của máy chủ trong quá trình SSL handshake. Nếu máy chủ tìm thấy session tương ứng trong bộ nhớ cache được lưu trước đó từ máy client (tức phiên trao đổi thỏa thuận key và thuật toán trước đó giữa client/server) thì sẽ máy chủ sẽ gửi gói “Server Hello” bao gồm Session Identifier cho client và tiến hành thực hiện Abbreviated SSL Handshake. Nếu không thấy session tương ứng trong cache thì máy chủ sẽ tạo ra Session Identifier hoàn toàn mới (hoặc New Session Ticket chứa các trạng thái session) và tiến hành Full SSL Handshake, vốn là tốn nhiều thời gian tính toán hơn Abbreviated SSL Handshake. Tuy nhiên, TLS Session Tickets hoạt động không được tốt nếu máy chủ có hỗ trợ Perfect Forward Secrecy (PFS) nên cần phải cân nhắc trước khi triển khai. Module detect TLS Session Ticket sẽ kết hợp với module detect Perfect Forward Secrecy trong hệ thống SSL Analysis, bởi vì nếu cả hai tính năng đó đều được bật cùng lúc trên server triển khai hạ tầng PKI thì TLS Session Ticket sẽ bị suy yếu đi. Chính vì thế mà mình quyết định tạo sự rành buộc bởi module PFS để thông báo cho người dùng biết tính năng TLS Session Ticket không phát huy tính hiểu quả vốn có của nó nếu server có hỗ trợ PFS.
Dưới đây là link demo dự án SSL Analysis: http://hsct.com.vn/ssllab/analysis.pl
HSTS (HTTP Strict Transport Security) là một tiêu chuẩn cho phép máy chủ website thực hiện truy vấn và yêu cầu cho trình duyệt biết trình duyệt chỉ có thể (bắt buộc) kết nối bằng một đường dẫn được mã hóa an toàn theo giao tiếp SSL/TLS (chẳng hạn như HTTPS) nhằm giúp người duyệt web tránh khỏi các cuộc tấn công của hacker bởi những thông tin nhạy cảm của người dùng đã bị tách rời và xáo trộn. Loại tấn công này xuất hiện trá hình dưới dạng các giao thức bảo mật HTTPS, giống như khi người dùng đăng nhập vào một tổ chức ngân hàng bằng cách sử dụng một hệ thống mạng không đáng tin cậy (chẳng hạng như các điểm truy cập Wi-Fi công cộng). Một trong số những lỗ hổng bảo mật quan trọng nhất mà tính năng HSTS có thể khắc chế được là SSL-stripping via Man-In-The-Middle Attack, là chuyển đổi kết nối HTTPS (secure) thành kết nối HTTP (non-secure) và hoạt động một cách bí mật mà người dùng không hề biết, nhắm vào tâm lý chủ quan của người dùng. Trong thời gian gần đây đã từng xảy ra việc một hacker ngồi ở một vị trí nào đó có thể theo dõi một người vào trang chủ của ngân hàng với những thông tin không được mã hóa, một phần là vì nguyên nhân website đó chưa kích hoạt tính năng HSTS, nhờ đó mà hacker này đã nhẹ nhàng “móc túi” của họ.
Cảm ơn bạn Nguyễn Dương Trung Hiếu (Freelancer) đã hỗ trợ mình viết thêm module detect HTTP Strict Transport Security để tích hợp vào hệ thống SSL Analysis. Module này được viết bằng ngôn ngữ lập trình GO với sự hỗ trợ đầy đủ bởi bộ công cụ phát triển Google App Engine (tương tự như Visual Studion bên Microsoft). Ngôn ngữ lập trình GO gần giống như C/C++ nhưng đã được tích hợp thêm những đặc tính hiện đại, kế thừa từ ngôn ngữ Python/Ruby và có đủ sự linh hoạt để sử dụng ngay trong trình duyệt Web. Hiếu là một coder đầu tiên được join vào dự án này và cũng là một trong số ít người Việt sử dụng ngôn ngữ GO. Module này tích hợp rất tốt với hệ thống SSL Analysis mà không gặp khó khăn nào đáng kể, nên đây cũng là một khởi đầu tốt cho một giải pháp nguồn mở (Open Source).
Link demo Project: http://hsct.com.vn/ssllab/analysis.pl
31/10/2012, mình đã viết xong một module mới là Perfect Forward Secrecy (PFS) và đã được tích hợp vào hệ thống SSL Analysis. Đây là tính năng quan trọng trong server triển khai hạ tầng PKI, trong đó một khóa bí mật dùng chung sẽ được làm mới khi kết hợp khóa hiện hành với một con số ngẫu nhiên (random number) để tạo ra một khóa mới bằng cách dùng khóa công cộng và kỹ thuật DH (Diffie-Hellman). PFS cho phép một khóa mới được tính toán lại mà không có mối liên quan nào đến khóa trước đó.
“Hầu hết các website có hỗ trợ HTTPS đều hoạt động dưới hình thức non-forward secret (không áp dụng forward secrecy), điều này dẫn đến một rủi ro gọi là “retrospective decryption”. Tức là kẻ tấn công sẽ ghi nhận và lưu trữ lại các traffic (request, response) được mã hóa, sau đó tìm cách để biết được private key như tập kết các siêu máy tính để thực hiện bẻ khóa private key trong nhiều năm hay dò trong ổ cứng chứa private key bị giục đi chẳng hạn. Khi đó, các traffic cũ này hoàn toàn có thể bị giải mã.” (trích Mẫn Thắng)
May thay, với forward secrecy, ta có thể giải quyết mối đe dọa trên. Khi nó được áp dụng thì một vài "thông tin cần thiết" để giải mã traffic được tạo ra ngẫu nhiên, khác nhau cho mỗi session và chúng bị hủy bỏ (không được lưu trữ lại) sau khi session giữa client và server chấm dứt. Đặc biệt, "thông tin cần thiết" này không liên quan tới các key được lưu trữ dài lâu là public key và private key nên nếu private key có bị "compromise" thì attacker cũng không thể nào giải mã được các thông điệp được mã hóa mà kẻ đó đã thu thập trước đó. Nói chung theo nghĩa khái quát, forward secrecy thực sự làm tăng tính riêng tư cho dữ liệu cần được bảo mật dài lâu.
08/11/2012, mình viết ra một tính năng mới giúp phát hiện và liệt kê các Anonymous Diffie-Hellman Cipher. Anonymous Diffie-Hellman là thuật toán Diffie-Hellman cơ bản được sử dụng mà không chứng thực, nghĩa là mỗi lần một bên gửi thông số Diffie-Hellman công khai của nó cho bên kia thì không xác thực. Điều này gần như là có thể bị tấn công bởi tấn công Man-in-the-middle ,trong đó kẻ tấn công điều khiển cả nhóm Anonymous Diffie-Hellman.
Trong quá trình HankShake, nếu Client và Server quyết định sử dụng thuật toán trao đổi khóa Anonymous Diffie Hellman thì trong phase 2 và phase 3 ở bước Server Key Exchange và Client Key Exchange sẽ xảy ra sự trao đổi các tham số ([g^a] mod p) cùa thuật toán và không có bất cứ sự xác thực nào. Do đó attacker có thể lợi dụng điểm yếu này để thực hiện tấn công Diffie Hellman Man-in-the-middle. Lúc này Attaker sẽ dùng hai khóa, một khóa giao dịch với Client và khóa còn lại giao dịch với Server, mặc dù cả Client và Server đều không nhận thấy có sự thay đổi bất thường.
Với Client (Victim), Attaker sẽ tạo ra một Digital Certificate giả mạo Server, Digital Certificate này khá giống với Digital Certificate của Server. Với Server, attacker tiến hành giao dịch như một Client thông thường. Khi giao dịch, trên Client sẽ xuất hiện những thông báo (warning) nhưng hầu hết người dùng đều bỏ qua những cảnh báo này. Kết quả là mọi thông tin trong quá trình giao dịch đều bị “nghe lén” bởi attacker.
Link demo Project: http://hsct.com.vn/ssllab/analysis.pl