Tôi chỉ đang tự hỏi. Chúng tôi sử dụng rất nhiều chứng chỉ SSL. Ngày nay, chúng tôi hầu như chỉ sử dụng letencrypt (cảm ơn!). Điểm mấu chốt của các chứng chỉ này là, bằng chứng về quyền sở hữu (các) tên miền trên chứng chỉ xuất phát từ khả năng thao túng các bản ghi DNS hoặc trang web trong các tên miền này. Bằng chứng DNS xuất phát từ việc thêm một số khóa (được đưa ra bởi letencrypt) dưới dạng bản ghi TXT vào DNS.

Vì vậy, NẾU đủ bằng chứng để có thể thay đổi bản ghi DNS cho một tên miền, tại sao không sử dụng chứng chỉ tự ký với dấu vân tay trong DNS?

Tôi muốn nói rằng điều này mang lại chính xác cùng mức độ tin cậy như thủ tục dựa trên DNS của letencrypt (và các CA khác):

1. Tạo một CA tự ký (chỉ cần làm theo các bước của nhiều cách khác nhau)
2. Tạo chứng chỉ cho một số tên miền
3. Ký chứng chỉ từ bước 2 với CA từ bước 1. Bây giờ bạn có chứng chỉ cơ bản, được ký bởi một CA không đáng tin cậy
4. Thêm bản ghi TXT (hoặc dành riêng) vào DNS của từng tên miền, cho biết: chúng tôi đã ký chứng chỉ của tên miền này với CA. Giống như: 'CA = -fingerpint của CA-'
5. Trình duyệt tải xuống chứng chỉ và xác minh bằng cách so sánh dấu vân tay của chứng chỉ CA / CA với dữ liệu trong DNS cho miền đã cho.

Điều này sẽ giúp tạo chứng chỉ tự ký đáng tin cậy mà không bị bên thứ ba can thiệp, có cùng mức độ tin cậy như bất kỳ chứng chỉ SSL cơ bản nào. Miễn là bạn có quyền truy cập vào DNS, chứng chỉ của bạn là hợp lệ. Người ta thậm chí có thể thêm một số DNSSEC như mã hóa, để tạo ra một hàm băm ra khỏi CA cộng với bản ghi SOA, để đảm bảo sự tin cậy biến mất khi thay đổi trong bản ghi DNS.

Điều này đã được xem xét trước?

Jelmer

Cơ sở hạ tầng cơ bản, sẽ biến điều này thành có thể, tồn tại và được gọi là Xác thực dựa trên DNS của các thực thể được đặt tên (Dane) và được chỉ định trong RFC6698 . Nó hoạt động bằng một TLSAbản ghi tài nguyên, chỉ định chứng chỉ hoặc khóa chung của thực thể cuối hoặc một trong các CA của nó trong chuỗi (Thực tế có bốn loại khác nhau, xem RFC để biết chi tiết).

Con nuôi

Dane tuy nhiên chưa thấy áp dụng rộng rãi. VeriSign giám sát việc áp dụng DNSSEC và Dane và theo dõi sự tăng trưởng của nó theo thời gian :

Để so sánh, theo VeriSign, tồn tại khoảng 2,7 triệu vùng DNS, do đó, điều đó có nghĩa là hơn 1% của tất cả các vùng có ít nhất một bản ghi TLSA.

Tôi không thể đưa ra bất kỳ câu trả lời có thẩm quyền nào, tại sao lại là Dane, nhưng đây là những suy đoán của tôi:

Dane bị vấn đề tương tự như Danh sách thu hồi chứng chỉ (CRL) và Giao thức trạng thái chứng chỉ trực tuyến (OCSP). Để xác minh tính hợp lệ của chứng chỉ được xuất trình, phải liên hệ với bên thứ ba. Hanno Böck đưa ra một cái nhìn tổng quan tốt , tại sao đây là một vấn đề lớn trong thực tế. Vấn đề là phải làm gì khi bạn không thể đến bên thứ ba. Các nhà cung cấp trình duyệt đã chọn không thành công (hay còn gọi là giấy phép) trong trường hợp này, điều này khiến cho toàn bộ điều này trở nên vô nghĩa và cuối cùng Chrome đã quyết định vô hiệu hóa OCSP vào năm 2012.

DNSSEC

Có thể cho rằng DNS cung cấp tính khả dụng tốt hơn nhiều so với các máy chủ CA của CRL và OCSP, nhưng nó vẫn không thể xác minh ngoại tuyến. Ngoài Dane, chỉ nên được sử dụng cùng với DNSSEC. Vì DNS bình thường hoạt động trên UDP không được xác thực, nên nó rất dễ bị giả mạo, các cuộc tấn công MITM, v.v. Việc áp dụng DNSSEC tốt hơn nhiều so với việc áp dụng Dane, nhưng vẫn còn rất phổ biến.

Và với DNSSEC, chúng tôi lại gặp vấn đề về lỗi mềm. Theo hiểu biết của tôi, không có hệ điều hành máy chủ / máy khách chính nào cung cấp trình phân giải DNSSEC hợp lệ theo mặc định.

Sau đó cũng là vấn đề thu hồi. DNSSEC không có cơ chế thu hồi và thay vào đó dựa vào các khóa tồn tại ngắn.

Hỗ trợ phần mềm

Tất cả các phần mềm tham gia phải thực hiện hỗ trợ Dane.

Về lý thuyết, bạn có thể nghĩ rằng đây sẽ là công việc của các thư viện tiền điện tử và các nhà phát triển ứng dụng sẽ không phải làm gì nhiều, nhưng thực tế là, các thư viện mật mã thường chỉ cung cấp các nguyên thủy và các ứng dụng phải tự thiết lập và cấu hình rất nhiều (và không may có nhiều cách để có được những điều sai).

Tôi không biết rằng bất kỳ máy chủ web lớn nào (ví dụ Apache hoặc nginx), ví dụ Dane đã triển khai hoặc có kế hoạch thực hiện. Các máy chủ web có tầm quan trọng đặc biệt ở đây, bởi vì ngày càng có nhiều công cụ được xây dựng trên các công nghệ web và do đó chúng thường là đầu tiên, nơi mọi thứ được triển khai.

Khi chúng ta xem CRL, OCSP và OCSP Stapling để so sánh, chúng ta có thể suy ra câu chuyện áp dụng Dane sẽ diễn ra như thế nào. Chỉ một số ứng dụng sử dụng OpenSSL, libnss, GnuTLS, v.v. mới hỗ trợ các tính năng này. Phải mất một thời gian để các phần mềm lớn như Apache hoặc nginx hỗ trợ nó và một lần nữa tham khảo lại bài viết của Hanno Böck, họ đã hiểu sai và việc triển khai của họ là thiếu sót. Các dự án phần mềm lớn khác, như Postfix hoặc Dovecot không hỗ trợ OCSPvà có chức năng CRL rất hạn chế, về cơ bản chỉ vào một tệp trong hệ thống tệp (không nhất thiết phải đọc lại quy định, do đó bạn sẽ phải tải lại máy chủ của mình theo cách thủ công, v.v.). Hãy nhớ rằng đây là những dự án thường xuyên sử dụng TLS. Sau đó, bạn có thể bắt đầu xem xét mọi thứ, trong đó TLS ít phổ biến hơn, chẳng hạn như PostgreSQL / MySQL và có thể họ cung cấp CRL tốt nhất.

Vì vậy, tôi thậm chí không có các máy chủ web hiện đại triển khai nó và hầu hết các phần mềm khác thậm chí không có mặt để triển khai OCSP và CRL, chúc may mắn với ứng dụng hoặc thiết bị doanh nghiệp 5 năm của bạn.

Ứng dụng tiềm năng

Vì vậy, nơi bạn thực sự có thể sử dụng Dane? Đến bây giờ, không phải trên Internet nói chung. Nếu bạn điều khiển máy chủ và máy khách, có thể đó là một tùy chọn, nhưng trong trường hợp này, bạn thường có thể sử dụng Ghim khóa công khai.

Trong không gian thư, Dane đang nhận được một số lực kéo, bởi vì SMTP không có bất kỳ loại mã hóa vận chuyển xác thực nào trong thời gian dài nhất. Các máy chủ SMTP đôi khi đã sử dụng TLS với nhau, nhưng không xác minh rằng tên trong các chứng chỉ thực sự khớp với nhau, giờ đây chúng bắt đầu kiểm tra điều này thông qua Dane.

Các loại thủ tục xác nhận chứng chỉ khác nhau

Với các chứng chỉ có chữ ký CA thông thường, có một số cấp độ xác thực chứng chỉ:

• Xác thực tên miền (DV)
  Chỉ quyền sở hữu tên miền được xác thực, chỉ tên miền được hiển thị là "Chủ đề" trong chứng chỉ
• Xác thực tổ chức (OV)
  Tên miền và tên chủ sở hữu được xác thực, tên miền và tên chủ sở hữu hiển thị dưới dạng "Chủ đề" trong chứng chỉ
• Xác thực mở rộng (EV)
  Xác thực nghiêm ngặt hơn về thực thể chủ sở hữu, tên miền và tên chủ sở hữu hiển thị dưới dạng "Chủ đề" trong chứng chỉ, thanh màu xanh lá cây có tên chủ sở hữu

Quá trình mà bạn mô tả và đề xuất thay thế, chỉ áp dụng cho cấp độ thấp nhất, Xác thực tên miền (DV).

DV là mức độ xác thực tương đối đơn giản để tự động hóa, chẳng hạn như những gì LetsEncrypt đã thực hiện và cung cấp mức độ tin cậy tương tự như những gì DNS có thể cung cấp nếu nó được sử dụng làm nguồn duy nhất cho neo tin cậy (ngụ ý UI, chứng chỉ có thể được tin cậy nhưng chứa dữ liệu bổ sung mà không có nghĩa là xác nhận).

Xác thực dựa trên DNS của các thực thể được đặt tên (Dane)

Dane xây dựng dựa trên DNSSEC (vì tính xác thực dữ liệu DNS là rất quan trọng) để xuất bản thông tin neo tin cậy cho các máy khách TLS trong DNS.

Nó sử dụng TLSAloại RR và có thể được sử dụng để xác định chứng chỉ hoặc khóa chung ( bộ chọn ) của thực thể cuối hoặc CA, có hoặc không yêu cầu xác thực chuỗi chứng chỉ thông thường để thành công ( sử dụng chứng chỉ ) và cách chứng nhận / dữ liệu chính được trình bày trong bản ghi ( loại khớp ).

Các TLSAtên chủ sở hữu kỷ lục có một tiền tố mà chỉ ra các cổng và giao thức (ví dụ _443._tcp) và rdata chỉ ra cert usage, selectorvà matching typecác chế độ, thêm vào các CERT / dữ liệu quan trọng để phù hợp. Xem phần 2.1 của RFC6698 để biết chi tiết cụ thể của các tham số này.

Một TLSAbản ghi có thể ví dụ như thế này:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

Với các chế độ sử dụng 2hoặc 3(biểu thị việc sử dụng neo tin cậy TLSA), khách hàng nhận biết Dane sẽ chấp nhận chứng chỉ không được ký bởi một CA đáng tin cậy nhưng phù hợp với TLSAhồ sơ.
Đây là khái niệm giống như những gì bạn đề xuất trong câu hỏi của bạn.

Cuộc đuổi bắt? Các máy khách nhận biết Dane hiện tại ít nhiều không tồn tại, một vấn đề là bản thân DNSSEC không được triển khai rộng rãi (đặc biệt là xác nhận trên máy khách) như những gì có thể được yêu cầu cho Dane cất cánh. Có khả năng là một chút vấn đề trứng gà, vì cho rằng Dane là một trong những trường hợp sử dụng mới có khả năng lớn đầu tiên dựa trên dữ liệu DNS được xác thực.

Có một plugin trình duyệt bổ sung xác thực DNSSEC và Dane , ngoài ra không có nhiều thứ ở gần chính thống vào thời điểm này. Và, là một plugin chứ không phải được hỗ trợ nguyên bản, nó phục vụ như một bằng chứng khái niệm hơn bất kỳ thứ gì khác khi nói đến sử dụng chung.

Nó có thể được thực hiện. Nó đã được xem xét. Nó vẫn có thể xảy ra, nhưng không có nhiều chuyển động.