Tim Hudson, Chủ tịch OpenSSL Corporation – Loạt Phỏng Vấn

Tim Hudson là đồng tác giả của SSLeay và là một trong những người tổ chức OpenSSL Conference, Prague từ 13‑15 tháng 10 năm 2026. Ông có hơn 30 năm kinh nghiệm trong bảo mật hệ thống và mạng, hiện là Chủ tịch của OpenSSL Corporation và Giám đốc Công nghệ tại Cryptsoft Pty Ltd. Kể từ năm 1995, công việc của ông bao gồm đồng sáng lập SSLeay cùng Eric Young, thư viện mật mã đã trở thành OpenSSL Library, đồng sáng lập trung tâm phát triển RSA Security Australia, đóng góp vào việc thay đổi các quy định xuất khẩu mã hoá của Hoa Kỳ, dẫn dắt hơn 30 lần xác thực FIPS 140, đồng chủ trì các ủy ban Kỹ thuật OASIS KMIP và SAM, và tham gia nói chuyện tại các hội nghị bảo mật hàng đầu, bao gồm RSA Conference, AusCERT, ICMC, LinuxConf và OpenSSL Conference.

OpenSSL là một dự án mã nguồn mở hợp tác toàn cầu, phát triển và duy trì OpenSSL Library, một trong những thư viện mật mã được sử dụng rộng rãi nhất trên thế giới. Được sử dụng trên các hệ điều hành, nền tảng đám mây, phần mềm doanh nghiệp và các thiết bị kết nối, OpenSSL Library giúp bảo vệ hàng tỷ tương tác trực tuyến an toàn mỗi ngày. Thông qua OpenSSL Foundation và OpenSSL Corporation, dự án cam kết thúc đẩy mật mã đáng tin cậy, hỗ trợ phát triển mã nguồn mở bền vững và tăng cường bảo mật cho Internet.

Bạn đã đồng sáng lập SSLeay với Eric Young vào năm 1995 sau khi nhận ra nhu cầu về một triển khai SSL không thuộc Hoa Kỳ, và công việc đó cuối cùng trở thành nền tảng cho OpenSSL. Vấn đề bạn muốn giải quyết ban đầu là gì, và vào thời điểm đó bạn có nhận thức rằng công nghệ này có thể trở thành một phần nền tảng trong việc bảo mật Internet không?

Vấn đề hoàn toàn mang tính cụ thể, và nó là một vấn đề thương mại trước khi trở thành bất cứ điều gì khác. Khi đó tôi đang làm việc tại Mincom ở Brisbane, và chúng tôi có khách hàng cần bảo mật các liên lạc của họ. Không có cách nào mua được khả năng đó. Các quy định xuất khẩu của Hoa Kỳ đối với mật mã có nghĩa là các sản phẩm Mỹ hoặc không thể cung cấp cho chúng tôi, hoặc chỉ có các kích thước khóa bị hạn chế đến mức triển khai chúng sẽ không trung thực. Đây không phải là một phản đối triết lý đối với chính sách xuất khẩu. Đó là một vấn đề kỹ thuật, trong đó thành phần tôi cần không tồn tại dưới bất kỳ hình thức nào mà tôi có thể mua, và tôi có khách hàng đang chờ đợi.

Điều tôi có là kiến thức về một thứ mà hầu hết mọi người đã quên. Eric Young đã viết một triển khai DES vài năm trước: mã tốt, sạch sẽ, có sẵn miễn phí, được viết vì mục đích riêng và hoàn toàn không liên quan đến bất kỳ điều gì ở trên. Eric không làm việc trên SSL. Anh ấy không biết đến SSL. Khi Netscape công bố bản đặc tả, tôi đã đọc nó, mang vấn đề đến cho Eric và trình bày nó như một bước đi tương đối khiêm tốn so với những gì anh ấy đã có.

Đây không phải là toàn bộ bức tranh. Mỗi phần đều đơn giản nhưng lại có một số lượng đáng kể các phần. Một triển khai DES cung cấp cho bạn một thuật toán mã hoá đối xứng. SSL yêu cầu mật mã khóa công khai, phép tính độ chính xác tùy ý, ASN.1, xử lý chứng chỉ X.509, và một máy trạng thái giao thức, tất cả đều phải đúng, vì trong mật mã, gần đúng và bị phá vỡ là điều tương đương. Tôi đã trình bày quy mô của nó một cách lạc quan. Eric sớm nhận ra mức độ phức tạp và thích thú, vì quy mô cuối cùng trở thành điểm thu hút chứ không phải là trở ngại. Tôi không chắc nếu nó sẽ bắt đầu theo cách khác.

Anh ấy thực hiện phần lõi mật mã, vì vậy thư viện mang tên viết tắt của anh ấy. Tôi chịu trách nhiệm các phần biến một thư viện thành thứ mà người khác có thể triển khai thực tế: tích hợp ứng dụng, kiểm thử, tài liệu và khía cạnh cộng đồng. Tôi cũng tích cực tìm kiếm bất kỳ thư viện mã hoá cạnh tranh nào đang được sử dụng và chuyển đổi hoặc thay thế chúng. SSLtelnet, SSLftp, NCSA httpd và nhiều gói khác là công việc của tôi, các ứng dụng được xây dựng trên các thuật toán và giao thức mật mã mà Eric đã triển khai. Sự kết hợp này cho phép mỗi người chúng tôi tập trung vào những gì thực sự thú vị với mình, và tôi nghĩ đó là lý do chính khiến dự án tiếp tục.

Việc ở Úc là yếu tố khiến việc giải quyết vấn đề trở nên khả thi, và sau đó chúng tôi nhận ra rằng rất nhiều người khác cũng gặp cùng một vấn đề vì cùng một lý do. Một giải pháp được xây dựng để đáp ứng yêu cầu cụ thể của khách hàng ở Brisbane đã trở nên hữu ích cho mọi người ngoài Hoa Kỳ, và cuối cùng cũng hữu ích cho nhiều người bên trong Hoa Kỳ.

Chúng tôi có biết nó sẽ trở thành gì không? Không. Không ai bắt đầu xây dựng cơ sở hạ tầng quan trọng. Cơ sở hạ tầng quan trọng là thứ bạn phát hiện ra mình đã xây dựng, vài năm sau, khi biết ai đang phụ thuộc vào nó. Những gì chúng tôi nghĩ mình đang làm là giải quyết một vấn đề trước mắt và sau đó trả lời các câu hỏi từ những người khác gặp cùng một rào cản. Phần trả lời câu hỏi đã quan trọng không kém phần mã nguồn.

Bạn đã làm việc trong lĩnh vực mật mã và bảo mật Internet hơn ba thập kỷ. Điều gì đã thay đổi đáng kể nhất trong bối cảnh đe dọa trong thời gian đó, và những vấn đề bảo mật nào vẫn bất ngờ tương đồng mặc dù công nghệ đã tiến bộ vượt bậc?

Sự thay đổi lớn nhất là việc tấn công hệ thống đã trở thành một nghề nghiệp với mô hình kinh tế phía sau. Vào giữa những năm 90, những người xâm nhập hệ thống chủ yếu làm vì tính thú vị. Ngày nay có một ngành công nghiệp, với chuyên môn, công cụ, chuỗi cung ứng, hỗ trợ khách hàng, và trong một số trường hợp là tài trợ của nhà nước. Điều này thay đổi mọi cách suy nghĩ, vì bạn không còn phòng thủ trước sự tò mò mà đang đối mặt với người có ngân sách, thời hạn và lý do kinh doanh.

Sự thay đổi thứ hai là quy mô và phụ thuộc. Ứng dụng trung bình năm 1995 là thứ bạn tự viết. Ứng dụng trung bình ngày nay là thứ bạn lắp ráp, và phần lớn mã trong đó được viết bởi những người bạn chưa từng gặp và không thể nêu tên. Bề mặt tấn công đã chuyển từ mã của bạn sang các phụ thuộc, và hầu hết các tổ chức chưa điều chỉnh cách suy nghĩ cho phù hợp.

Điều vẫn bất ngờ ổn định là các chế độ thất bại. Chúng ta vẫn viết lỗi trong mã phân tích dữ liệu không tin cậy. Chúng ta vẫn phát hành hệ thống với các cấu hình mặc định mà không ai xem xét lại. Chứng chỉ vẫn hết hạn vào thứ Bảy. Thông tin đăng nhập vẫn rơi vào những nơi không nên. Và mật mã hầu như không bao giờ bị phá vỡ ở mức toán học. Nó bị bỏ qua, cấu hình sai, hoặc đơn giản là không được bật. Nếu bạn đưa cho tôi danh sách mười nguyên nhân gốc gây rò rỉ năm 1996 và một danh sách từ tháng trước, bạn sẽ khó phân biệt chúng. Công nghệ đã hoàn toàn biến đổi. Những sai lầm thì không.

OpenSSL 4.0 được phát hành vào tháng 4 năm 2026, đánh dấu bản phát hành lớn đầu tiên của dự án trong nhiều năm. Bản phát hành này cho chúng ta thấy hướng đi của hạ tầng mật mã như thế nào, và những thay đổi nào bạn cho rằng sẽ quan trọng nhất đối với các tổ chức phụ thuộc vào OpenSSL?

Điều hữu ích nhất cần hiểu về 4.0 là nó chủ yếu là một bản phát hành giảm bớt, và đó chính là mục đích của nó.

Chúng tôi đã loại bỏ hoàn toàn giao diện ENGINE. Chúng tôi đã loại bỏ SSLv3 và SSLv2 ClientHello. Chúng tôi đã tắt các đường cong elliptic đã lỗi thời và các đường cong EC rõ ràng ở thời điểm biên dịch. Chúng tôi đã làm cho ASN1_STRING trở nên không công khai và siết chặt một số lượng lớn các chữ ký API. Đó là những thay đổi tạo ra công việc cho người dùng, và cũng là những thay đổi quan trọng, vì một thư viện mật mã chỉ tích lũy mà không loại bỏ không thể duy trì an toàn. Mỗi lối đi mã đã lỗi thời mà bạn giữ lại là một bề mặt tấn công mà ai đó duy trì thay bạn và không ai kiểm tra.

Có một số bổ sung: Encrypted Client Hello, hỗ trợ RFC 8998 bao gồm nhóm hỗn hợp SM2/ML-KEM, cSHAKE, SNMP và SRTP KDFs, FFDHE đàm phán cho TLS 1.2. Đặc biệt, ECH đóng một khoảng trống thực sự về quyền riêng tư, vì Server Name Indication đã rò rỉ danh tính của mọi trang web bạn truy cập kể từ khi TLS 1.3 được phát hành. Nhưng những phần bị loại bỏ mới là câu chuyện chính.

Điều tôi muốn các tổ chức nắm bắt nhất là: 4.0 không phải là bản phát hành LTS. Nó được hỗ trợ đến tháng 5 năm 2027. Bản phát hành ổn định dài hạn hiện tại là 3.5, được hỗ trợ đến tháng 4 năm 2030, và 3.5 đã có các thuật toán hậu lượng tử. Nếu bạn muốn mã mới nhất, hãy sử dụng 4.0. Nếu bạn muốn một mục tiêu ổn định để xây dựng kế hoạch di chuyển trong năm năm, hãy dùng 3.5. Lựa chọn số cao hơn chỉ vì nó cao hơn là một sai lầm chúng tôi thấy mọi người mắc trong mỗi chu kỳ.

Mật mã hậu lượng tử đã chuyển từ một vấn đề nghiên cứu sang thách thức di chuyển, với OpenSSL đã hỗ trợ ML-KEM, ML-DSA và SLH-DSA cùng trao đổi khóa hậu lượng tử hỗn hợp. Đối với các nhà lãnh đạo doanh nghiệp cho rằng máy tính lượng tử vẫn còn quá xa để lo lắng, những rủi ro nào họ đang bỏ qua hiện nay?

Lỗi phổ biến nhất là coi đây là câu hỏi về thời điểm máy tính lượng tử có khả năng mật mã xuất hiện. Đó là biến sai. Câu hỏi đúng là dữ liệu của bạn cần giữ bí mật trong bao lâu, và quá trình di chuyển sẽ mất bao lâu. Lấy thời gian di chuyển trừ thời gian bảo mật, bạn có được thời hạn thực tế, và đối với nhiều tổ chức thời hạn đó đã qua rồi.

Lưu lượng mã hoá có thể bị bắt ngay hôm nay và lưu trữ vô hạn. Nếu thông tin trong đó có độ nhạy cảm kéo dài hai mươi năm (hồ sơ bệnh nhân, hồ sơ nhân sự, sở hữu trí tuệ, tài liệu ngoại giao, vị thế tài chính), kẻ thù không cần máy tính lượng tử ngay lập tức. Họ chỉ cần một chiếc máy trong tương lai, và lưu trữ rẻ trong thời gian chờ đợi. Đó không phải là một cuộc tấn công suy đoán; đó là một quyết định lưu trữ.

Điều thứ hai bị bỏ qua là việc di chuyển không phải là một dự án duy nhất. Trao đổi khóa là phần dễ, và phần lớn đã diễn ra: OpenSSL 3.5 đã làm cho trao đổi khóa hậu lượng tử hỗn hợp trở thành mặc định TLS, vì vậy rất nhiều tổ chức đang sử dụng thỏa thuận khóa hậu lượng tử ngay bây giờ mà chưa quyết định về nó. Chữ ký và cấu trúc chứng chỉ là phần khó, vì chúng liên quan đến các cơ quan chứng chỉ, gốc tin cậy phần cứng, khóa ký firmware, mô-đun bảo mật phần cứng, và các thiết bị có tuổi thọ thực địa mười lăm năm được xây dựng dựa trên giả định RSA sẽ luôn ổn.

Điều thứ ba là ràng buộc mà không ai dự trù ngân sách: chữ ký hậu lượng tử có kích thước lớn. Một chữ ký ML-DSA-65 có kích thước khoảng năm mươi lần chữ ký ECDSA P-256, và SLH-DSA còn lớn hơn. Điều này gây ra vấn đề: kích thước bắt tay, thiết bị hạn chế, giao thức có giới hạn trường cố định, liên kết vệ tinh và IoT. Bạn phát hiện những vấn đề này bằng cách thử nghiệm, không phải bằng việc đọc tiêu chuẩn.

Một trong những thách thức của việc di chuyển hậu lượng tử là các tổ chức có thể không biết được mọi nơi mà mật mã được sử dụng trong các ứng dụng, hạ tầng, thiết bị và phụ thuộc của bên thứ ba. Các công ty nên tiếp cận việc kiểm kê mật mã và tính linh hoạt mật mã như thế nào để chuyển đổi thuật toán lớn tiếp theo không trở thành trường hợp khẩn cấp?

Bắt đầu bằng một sự thật khó chịu: bạn không thể xây dựng một kiểm kê mật mã bằng cách gửi bảng câu hỏi cho các nhà cung cấp. Bạn sẽ nhận được một hỗn hợp giữa bản sao tiếp thị, sự không chắc chắn trung thực, và các câu trả lời đã đúng ba phiên bản trước. Tôi nói điều này sau khi dành thời gian đáng kể gần đây để đọc tài liệu của các nhà cung cấp phần cứng trong một lĩnh vực liên quan, và khoảng cách giữa những gì tài liệu khẳng định và những gì sản phẩm thực tế làm lớn hơn so với những gì hầu hết người mua giả định.

Bạn phải tự kiểm tra. Có ba lớp, và mỗi lớp cần kỹ thuật khác nhau. Mã bạn viết: phân tích tĩnh, quét phụ thuộc, và tìm kiếm các định danh thuật toán mà bạn đã mã hoá cứng nhiều năm trước. Mã bạn liên kết: danh sách vật liệu phần mềm, mở rộng thành danh sách vật liệu mật mã, nơi công việc CBOM thực sự hữu ích. Các thứ bạn mua hoặc kết nối: quan sát mạng, vì những gì hệ thống của bạn thực sự đàm phán trên dây là sự thật cơ bản và thường không phải là những gì ai đó tin tưởng.

Về tính linh hoạt, nguyên tắc đơn giản nhưng thực tiễn không: thuật toán nên là quyết định cấu hình, không phải thay đổi mã. Nếu việc thay đổi một thuật toán mã hoá yêu cầu một nhà phát triển, một bản dựng, một chu kỳ kiểm thử và một bản phát hành, bạn không có tính linh hoạt. Bạn đang có một dự án. Hợp nhất các hoạt động mật mã phía sau một giao diện bạn kiểm soát, để có một nơi duy nhất để thay đổi thay vì bốn trăm nơi.

Và phần mà hầu hết mọi người bỏ qua: thực hành nó. Tính linh hoạt mà bạn chưa bao giờ sử dụng chỉ là một tuyên bố, không phải là khả năng. Chọn một cuối tuần yên tĩnh, tắt một thuật toán trong môi trường không sản xuất, và xem gì bị phá vỡ. Sẽ có thứ gì đó. Tốt hơn là phát hiện nó theo lịch trình của bạn hơn là trong một chuyển đổi khẩn cấp bắt buộc.

Một yếu tố ép buộc hữu ích là thời gian sống của chứng chỉ. Ngành đang chuyển sang chứng chỉ có thời hạn ngắn hơn đáng kể, điều này làm cho việc quản lý chứng chỉ thủ công trở nên không khả thi và buộc phải tự động hoá mà bạn đã dự định cần. Nếu bạn tự động hoá việc phát hành và quay vòng chứng chỉ một cách đúng đắn, bạn đã xây dựng hầu hết cơ chế mà một chuyển đổi thuật toán trong tương lai sẽ yêu cầu.

AI đang thay đổi cả phòng thủ an ninh mạng và khả năng của kẻ tấn công. Bạn tin rằng AI thực sự thay đổi yếu tố nào trong phương trình bảo mật, và bạn cho rằng các tổ chức có thể đang quá tập trung vào công nghệ mà bỏ qua những điểm yếu cơ bản hơn?

AI thực sự thay đổi một điều, và tôi có thể nói trực tiếp vì nó đã xảy ra với chúng tôi.

Một số lượng đáng kể các lỗ hổng được công bố trong OpenSSL năm nay đã được phát hiện bằng phân tích dựa trên AI. Vào tháng Một, chúng tôi phát hành một bản cập nhật sửa mười hai vấn đề, hầu hết từ một nhóm nghiên cứu sử dụng phân tích tự động, và họ đã đóng góp các bản vá cùng với báo cáo. Vào tháng Sáu, chúng tôi sửa một lỗi sử dụng sau giải phóng nghiêm trọng trong việc xác minh PKCS#7 được một nhà nghiên cứu phát hiện khi làm việc với một hệ thống AI. Đó là một thay đổi khả năng thực tế trong việc tìm ra lỗi an toàn bộ nhớ và lỗi phân tích trong mã C đã được các chuyên gia xem xét trong nhiều năm. Tôi đã thấy cùng một mô hình trong các thư viện mật mã khác. Khi phân tích một loạt CVE của Bouncy Castle trong năm nay, dấu vân tay của phân tích mã tự động rất rõ ràng.

Hệ quả rõ ràng là điều này có hai mặt. Các kỹ thuật tương tự có sẵn cho bất kỳ ai muốn sử dụng chúng, trên cùng một cơ sở mã, và những người bảo vệ không có quyền truy cập độc quyền.

Hệ quả ít rõ ràng hơn, và điều tôi muốn nhấn mạnh, là gánh nặng nó đặt lên các người duy trì. Tạo ra một báo cáo lỗ hổng trông hợp lý hiện nay gần như miễn phí. Tuy nhiên việc phân loại một báo cáo không phải vậy. Nó vẫn tốn thời gian thực của một chuyên gia con người. Các nhóm bảo mật mã nguồn mở, thường nhỏ và thường là tình nguyện, đang phải chịu một khối lượng báo cáo ngày càng tăng với chất lượng rất đa dạng. Những báo cáo tốt, như nghiên cứu tôi đã đề cập, đi kèm với các công cụ tái tạo và bản vá. Những báo cáo kém là một cuộc tấn công từ chối dịch vụ đối với những người bạn phụ thuộc. Nếu tổ chức của bạn đang triển khai AI để phân tích mã nguồn mở, hãy tài trợ cho khả năng phân loại ở phía bên kia.

Nơi tôi cho rằng sự chú ý bị đặt sai chỗ: AI không tự vá các hệ thống của bạn. Nó không thực hiện kiểm kê tài sản, không quay vòng thông tin đăng nhập, không loại bỏ phần cứng không được hỗ trợ, và không khiến ai chịu trách nhiệm cho chứng chỉ sẽ hết hạn vào tháng tới. Các tổ chức mua công cụ bảo mật AI trong khi chạy phần mềm có lỗ hổng chưa được vá đã sắp xếp thứ tự sai. Công việc không hào nhoáng vẫn là nơi rủi ro tồn tại.

Nhiều tổ chức đầu tư mạnh vào công cụ nhưng vẫn còn dễ bị tấn công do lỗi cấu hình, hệ thống lỗi thời, quy trình yếu kém hoặc chuẩn bị sự cố không đầy đủ. Những sai lầm bảo mật quan trọng nhất mà bạn vẫn thấy là gì, và các đội lãnh đạo nên có gì trước khi một cuộc tấn công thực sự xảy ra?

Sai lầm quan trọng nhất là coi bảo mật như một hoạt động mua sắm. Công cụ được mua, ngân sách được đáp ứng, bảng điều khiển xanh, và không ai hỏi liệu tổ chức thực sự có thể thực hiện những việc cơ bản hay không.

Sai lầm thứ hai là không biết mình đang chạy gì. Bạn không thể vá phần mềm mà bạn không biết mình có, và hầu hết các tổ chức phát hiện nội dung thực tế của tài sản khi có sự cố. Đó là lý do công việc danh sách vật liệu quan trọng, không phải như một tài liệu tuân thủ mà là thứ bạn tìm vào lúc 2 giờ sáng khi có một khuyến cáo quan trọng và ai đó hỏi liệu bạn có bị ảnh hưởng không.

Sai lầm thứ ba là cấu hình mặc định. Hệ thống được cài đặt, hoạt động, và cấu hình không bao giờ được xem xét lại. Năm năm sau, cấu hình đó trở thành một rủi ro, và không ai trong những người quyết định ban đầu còn làm việc ở đó.

Sai lầm thứ tư là quản lý khóa và chứng chỉ được giao cho cá nhân. Một tỷ lệ đáng chú ý các sự cố tự gây ra là do chứng chỉ hết hạn mà một người đã theo dõi trong bảng tính một cách yên lặng cho đến khi họ chuyển công việc.

Trước khi có sự cố, lãnh đạo cần có bốn yếu tố. Một người quyết định được chỉ định có thẩm quyền tắt hoạt động kinh doanh, được quyết định trước và bằng văn bản, vì tranh luận về ai có thẩm quyền không phải là điều bạn muốn xảy ra khi đang diễn ra. Các hợp đồng dịch vụ đã ký với các công ty pháp y bên ngoài và cố vấn chuyên môn, vì việc mua sắm này mất vài tuần còn bạn chỉ có vài giờ. Một kênh truyền thông không phụ thuộc vào các hệ thống có thể bị xâm phạm. Và một khả năng khôi phục đã được kiểm tra thực tế từ đầu đến cuối, không phải một chế độ sao lưu chỉ được xác nhận ở mức các công việc đã hoàn thành thành công.

Sau đó, hãy luyện tập. Một buổi diễn tập mô phỏng tại cấp điều hành, một lần mỗi năm, sẽ phát hiện nhiều khoảng trống thực tế hơn so với một công cụ khác.

Khi một cuộc tấn công mạng nghiêm trọng xảy ra, các nhà điều hành có thể đột ngột phải đưa ra các quyết định kỹ thuật, pháp lý, vận hành và truyền thông dưới áp lực lớn. Điều gì phân biệt các tổ chức phản hồi hiệu quả với những tổ chức để sự cố trở nên tồi tệ hơn đáng kể?

Các tổ chức xử lý tốt đã đưa ra các quyết định quan trọng trước khi xảy ra sự cố, vì vậy trong khi sự cố diễn ra họ thực hiện thay vì suy nghĩ. Đó là phần lớn.

Ngoài việc chuẩn bị, một vài yếu tố luôn phân biệt phản hồi tốt và xấu.

Họ tách riêng cuộc điều tra kỹ thuật khỏi luồng điều hành và truyền thông, với một giao diện định nghĩa giữa chúng. Khi cùng một nhóm người cố gắng kiềm chế xâm nhập và soạn thông báo cho khách hàng, cả hai công việc đều bị thực hiện kém.

Họ bảo toàn bằng chứng trước khi khắc phục. Bản năng tái xây dựng máy bị xâm phạm ngay lập tức rất mạnh và phá hủy thông tin cần thiết để xác định phạm vi. Nếu bạn không thể trả lời “còn gì họ đã chạm tới,” bạn không thể thuyết phục ai rằng sự cố đã kết thúc.

Họ chấp nhận rằng thông tin ban đầu là tạm thời và truyền thông phù hợp. Phần lớn thiệt hại về uy tín tôi quan sát được không phải do vụ rò rỉ mà do những tuyên bố tự tin sớm phải rút lại. Nói “đây là những gì chúng tôi biết, đây là những gì chúng tôi chưa biết, đây là thời điểm chúng tôi sẽ cập nhật cho bạn” không phải là điểm yếu. Đó là vị trí duy nhất bạn sẽ không phải đảo ngược.

Và quan trọng: họ tạo ra môi trường cho các kỹ sư có thể nói với nhà điều hành những tin xấu. Mô hình thất bại tôi thấy thường nhất là một tổ chức mà rủi ro pháp lý quá rõ ràng khiến không ai muốn là người ghi lại những gì thực sự đã xảy ra. Khi đó sự cố trở nên tồi tệ hơn trong im lặng. Nếu các kỹ sư của bạn đang quản lý trách nhiệm cá nhân thay vì sự cố, bạn đang có một vấn đề quản trị mà không công cụ nào có thể khắc phục.

OpenSSL nằm trong vị trí đặc biệt là cơ sở hạ tầng mã nguồn mở quan trọng được sử dụng trong toàn bộ hệ sinh thái công nghệ, trong khi OpenSSL Corporation tập trung phục vụ cộng đồng thương mại cùng với OpenSSL Foundation độc lập vận hành. Bạn cân bằng nhu cầu của doanh nghiệp, nhà phát triển, cơ quan quản lý và cộng đồng mã nguồn mở rộng lớn như thế nào khi các quyết định về bảo mật và tương thích có thể ảnh hưởng đến một phần lớn của Internet?

Câu trả lời trung thực là bạn không cân bằng chúng bằng cách cố gắng làm hài lòng mọi người trong mỗi quyết định. Bạn cân bằng chúng bằng cách có một chính sách công khai và áp dụng một cách dự đoán được, để mọi người có thể lập kế hoạch quanh bạn ngay cả khi họ không thích một kết quả cụ thể.

Tính dự đoán là những gì chúng tôi nợ người dùng. Chúng tôi phát hành các bản cập nhật tính năng vào tháng 4 và tháng 10. Chúng tôi thông báo trước bản nào là ổn định dài hạn và đến khi nào. Chúng tôi công bố các việc loại bỏ quan trọng trước khi chúng diễn ra. Việc loại bỏ ENGINE trong 4.0 đã được mô tả công khai vài tháng trước khi phát hành, và được cả Corporation và Foundation đồng ý. Ai bất ngờ vào tháng 4 đã không chú ý, và chúng tôi đã làm cho việc chú ý trở nên dễ dàng nhất có thể.

Câu trả lời cấu trúc là sự tách biệt tự nó. Foundation tồn tại để phục vụ thư viện mã nguồn mở và cộng đồng xung quanh. Corporation tồn tại để phục vụ các tổ chức có yêu cầu thương mại (cam kết hỗ trợ, xác thực FIPS, thời gian cụ thể) và để làm cho toàn bộ dự án bền vững về tài chính. Giữ chúng tách biệt có nghĩa là không nhu cầu nào bị giải quyết âm thầm theo phía còn lại. Khi yêu cầu doanh nghiệp và yêu cầu cộng đồng thực sự xung đột, xung đột đó xảy ra giữa hai tổ chức có nhiệm vụ rõ ràng thay vì trong đầu một người.

Phần còn lại là lắng nghe đúng cách, điều này đòi hỏi các cơ chế thực tế thay vì giả định. Đó là một phần lớn lý do chúng tôi tổ chức hội nghị, diễn ra ở Prague vào tháng Mười này, và lý do tồn tại cơ sở hạ tầng cộng đồng. Rất dễ cho các người duy trì phát triển các giả thuyết tự tin về những gì người dùng cần. Thực tế, việc có mặt trong cùng một phòng với họ hữu ích hơn rất nhiều.

10. Nhìn vào thập kỷ tới, chuyển đổi bảo mật hoặc mật mã nào bạn cho rằng các tổ chức vẫn đang đánh giá thấp hiện nay, và những bài học nào từ sự phát triển của SSL, OpenSSL và 30 năm an ninh Internet qua đi mà các nhà lãnh đạo nên áp dụng khi chuẩn bị cho nó?

Chuyển đổi mà tôi cho là bị đánh giá thấp nhất không phải là mật mã hậu lượng tử như một vấn đề thuật toán. Đó là danh tính máy và cấu trúc chứng chỉ nằm dưới mọi thứ.

Trao đổi khóa hậu lượng tử sẽ được giải quyết phần lớn bằng các cấu hình mặc định, và phần lớn đã được thực hiện. Điều mà các cấu hình mặc định không giải quyết được là hạ tầng tin cậy: các chứng chỉ gốc trong phần cứng, khóa ký firmware được khắc vào thiết bị, HSM có tuổi thọ còn lại một thập kỷ, hệ thống công nghiệp và y tế sẽ vẫn hoạt động đến năm 2040 với các giả định mật mã được tích hợp khi sản xuất. Những thứ này không thể được cập nhật chỉ bằng cách phát hành một phiên bản thư viện mới, và trong một số trường hợp không thể cập nhật được. Quy mô của vấn đề thay thế này hiện chưa được phản ánh trong kế hoạch vốn của bất kỳ ai.

Cùng với đó là một chuyển đổi về quy định. Đạo luật An ninh mạng (Cyber Resilience Act) ở châu Âu, và các khung pháp lý tương tự ở các nơi khác, sẽ thay đổi các nghĩa vụ liên quan đến việc phát hành phần mềm có thành phần bạn không tự viết. Hầu hết các tổ chức chưa xem xét điều này ảnh hưởng như thế nào đến sự phụ thuộc của họ vào mã nguồn mở, hoặc đối với những người duy trì nó.

Ba bài học từ ba mươi năm:

1. Chuyển đổi mất thời gian dài hơn một thập kỷ so với thông báo. SSLv3 đã bị ngừng sử dụng vào năm 2015, bị tắt mặc định vào năm 2016, và chúng tôi cuối cùng mới loại bỏ mã vào tháng 4 năm 2026. Đó là mười một năm, cho một giao thức mà mọi người đều đồng ý là đã bị hỏng. Lập kế hoạch di chuyển hậu lượng tử dựa trên thực tế này, không phải dựa trên thông cáo báo chí.
2. Cấu hình mặc định là biện pháp bảo mật duy nhất hoạt động ở quy mô lớn. Bất kỳ