it-swarm-vi.com

Tôi nên sử dụng mật mã nào trong máy chủ web của mình sau khi định cấu hình chứng chỉ SSL?

Có rất nhiều câu hỏi hay hỏi xem chứng chỉ tốt nhất để sử dụng cho trang web là gì; nhưng một khi chứng chỉ được mua, cũng có khả năng chọn hoặc chỉnh sửa danh sách Mật mã.

Mặc dù mỗi nhà cung cấp có thể gọi cài đặt này là một cái gì đó hơi khác nhau, nhưng sự hiểu biết của tôi là Danh sách Mật mã được sử dụng để đàm phán các giao thức mã hóa giữa máy khách và máy chủ.

  1. Những điều cơ bản của việc chọn danh sách Mật mã cho trang web của tôi là gì? Nếu các mặc định cần phải được thay đổi, "người mới bắt đầu" nên đi đâu để nhận được lời khuyên đáng tin cậy?

  2. Có bất kỳ khuyến nghị truyền thống nào đã thay đổi kể từ cuộc tấn công CRIME của BEAST hoặc 2012 không?

  3. Có ai duy trì một danh sách các mật mã được hỗ trợ bởi OS/Vendor/và phiên bản không? Là chính xác để nói rằng một cái gì đó như thế này sẽ hữu ích?

  4. Là một số chứng chỉ không tương thích hoặc không được ưa thích với một số mật mã nhất định?

  5. Tôi có thể tìm hiểu thêm ở đâu? Cụ thể, làm thế nào tôi có thể có được một khả năng thảo luận để so sánh Ciphers mà không phải học lại một số lớp toán sau trung học?

30
goodguys_activate

Trong SSL/TLS , bộ mật mã chọn một bộ thuật toán, cho một số tác vụ: thỏa thuận khóa, mã hóa đối xứng, kiểm tra tính toàn vẹn.

Loại chứng chỉ tác động đến việc lựa chọn thỏa thuận chính. Phải tính đến hai tham số: the loại khóa sử dụng khóa:

  • Với khóa RSA, bạn có thể sử dụng bộ mật mã "RSA" và "DHE_RSA". Nhưng nếu chứng chỉ máy chủ có tiện ích mở rộng Sử dụng khóa có không bao gồm cờ "keyEncodesment", thì bạn bị giới hạn ở mức "DHE_RSA".
  • Với khóa DSA, bạn chỉ có thể sử dụng bộ mật mã "DHE_DSS".
  • Với khóa Diffie-Hellman, bạn chỉ có thể sử dụng một trong số "DH_RSA" hoặc "DH_DSS", tùy thuộc vào loại khóa ủy quyền chứng chỉ phát hành.

Hầu hết các chứng chỉ máy chủ SSL đều có khóa RSA không bị hạn chế thông qua tiện ích mở rộng Sử dụng khóa, do đó bạn có thể sử dụng cả hai loại khóa "RSA" và "DHE_RSA".

"DHE" là viết tắt của "Diffie-Hellman Ephemeral". Điều này cho phép Bí mật chuyển tiếp hoàn hảo . PFS có nghĩa là nếu kẻ tấn công đánh cắp khóa riêng của máy chủ (khóa được lưu trữ trong tệp, do đó rất dễ bị đánh cắp bí mật), anh ta vẫn không thể giải mã được các giao dịch đã ghi. Đây là một tài sản mong muốn, đặc biệt là khi bạn muốn hệ thống của bạn trông tốt trong quá trình kiểm toán.

Đối với kiểm tra tính toàn vẹn , bạn không nên sử dụng MD5 và nếu có thể, hãy tránh SHA-1. Không có điểm yếu nào được biết đến hiện tại của MD5 và SHA-1 ảnh hưởng đến bảo mật của TLS (trừ khi có thể được sử dụng trong một chứng chỉ, nhưng đó là do CA chọn, không phải bạn). Tuy nhiên, sử dụng MD5 (hoặc, ở mức độ thấp hơn, SHA-1) có hại cho quan hệ công chúng. MD5 bị "hỏng". Nếu bạn sử dụng MD5, bạn có thể phải tự biện minh. Không ai có thể đặt câu hỏi về sự lựa chọn của SHA-256. Sự đồng thuận chung là SHA-1 là "chấp nhận được" vì lý do di sản.

Đối với mã hóa đối xứng , bạn có quyền lựa chọn giữa (hầu hết) RC4, 3DES và AES (đối với phiên bản sau, phiên bản 256 bit là quá mức cần thiết; AES- 128 đã ổn rồi). Những điểm sau đây có thể được thực hiện:

  • RC4 và 3DES sẽ được hỗ trợ ở mọi nơi. Các máy khách cũ nhất có thể không hỗ trợ AES (ví dụ: Internet Explorer 6.0 dường như không thể đàm phán các bộ mật mã dựa trên AES).

  • Có những điểm yếu được biết đến trong RC4. Không có gì là gây tử vong ngay lập tức. Tình huống có phần giống với tình huống của SHA-1: "vỡ" về mặt học thuật, nhưng không phải là vấn đề ngay bây giờ. Đây vẫn là một lý do tốt để không sử dụng RC4 nếu có thể tránh được.

  • 3DES là một mật mã khối 64 bit. Điều này hàm ý một số điểm yếu (hàn lâm) khi bạn mã hóa nhiều hơn một vài gigabyte trong một phiên.

  • 3DES có thể nặng về CPU của bạn. Trên Intel i7 2,7 GHz, OpenSSL đạt tốc độ mã hóa 180 MB/giây với AES-128 (nó có thể làm tốt hơn nhiều nếu sử dụng hướng dẫn AES-NI ) nhưng chỉ 25 MB/s với 3DES. 25 MB/s vẫn tốt (gấp 2,5 lần so với liên kết 100 Mbits/giây và sử dụng một lõi) nhưng có thể không đáng kể, tùy thuộc vào tình huống của bạn.

  • Cuộc tấn công BEAST là một điểm yếu học thuật cũ gần đây đã được chứng minh là có thể áp dụng trong thực tế. Nó yêu cầu kẻ tấn công gián điệp trên liên kết chạy mã thù địch trên máy khách (và mã đó phải giao tiếp với hệ thống gián điệp bên ngoài); các tác giả BEAST đã quản lý để chạy nó khi mã nội bộ thù địch sử dụng Java hoặc Javascript. Giải pháp chung là chuyển sang TLS 1.1 hoặc 1.2, miễn dịch. Ngoài ra, điều này chỉ liên quan đến thuật toán mã hóa trong chế độ CBC, RC4 là miễn dịch.

  • Trong một cái bắt tay SSL/TLS, khách hàng thông báo các bộ mật mã được hỗ trợ của mình (bộ ưu tiên đến trước), sau đó máy chủ chọn bộ sẽ được sử dụng. Đó là truyền thống rằng máy chủ tôn vinh các tùy chọn của máy khách - tức là chọn bộ đầu tiên trong danh sách được gửi bởi máy khách mà máy chủ có thể xử lý. Nhưng một máy chủ có thể thực thi thứ tự ưu tiên riêng của nó.

  • DHE ngụ ý mức tiêu thụ CPU cao hơn một chút trên máy chủ (nhưng nó sẽ không tạo ra sự khác biệt đáng chú ý trừ khi bạn thiết lập hàng trăm phiên SSL mới mỗi giây).

  • Không có bộ mật mã DHE sử dụng RC4.

Tóm tắt: điều này dẫn tôi đến danh sách các bộ mật mã ưa thích sau đây. Nếu cuộc tấn công BEAST có thể áp dụng cho bạn (tức là máy khách là trình duyệt Web), hãy sử dụng:

  • Nếu phiên sử dụng SSL-3.0 hoặc TLS-1.0, hãy thử sử dụng TLS_RSA_WITH_RC4_128_SHA.
  • Nếu máy khách hỗ trợ TLS 1.1+ hoặc nếu nó không hỗ trợ TLS_RSA_WITH_RC4_128_SHA hoặc nếu bạn coi PFS quan trọng với bạn hơn các cuộc tấn công hoạt động giống như BEAST (ví dụ: bạn quan tâm nhất đến bảo mật lâu dài, không vi phạm ngay lập tức), thì hãy sử dụng TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dự phòng cho TLS_DHE_RSA_WITH_AES_128_CBC_SHA nếu máy khách không hỗ trợ SHA-256).
  • Nếu bộ mật mã DHE không được máy khách hỗ trợ, hãy sử dụng bộ không phải DHE tương ứng.
  • Dự phòng chung là TLS_RSA_WITH_3DES_EDE_CBC_SHA mà nên làm việc ở khắp mọi nơi.

Lưu ý rằng các lựa chọn ở trên giả định rằng bạn có thể thay đổi lựa chọn bộ tùy thuộc vào phiên bản giao thức được đàm phán, có thể hoặc không phải là một tùy chọn khả dụng cho máy chủ SSL cụ thể của bạn.

Nếu BEAST không áp dụng cho bạn (máy khách sẽ không chạy mã thù địch), sau đó bỏ hoàn toàn hỗ trợ RC4; tập trung vào AES-128 và SHA-256; dự phòng trên 3DES và SHA-1, tương ứng; sử dụng DHE nếu có.

29
Thomas Pornin

Tôi thích bộ mật mã được đề xuất bởi Mozilla (Vào tháng 1 năm 2014):

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

nguồn: https://wiki.mozilla.org/Security/Server_Side_TLS

nó cố gắng cân bằng hiệu suất và bảo mật. Tuy nhiên, như khuyến nghị Microsoft của tôi , tôi sẽ tránh xa RC4

2
VP.

Các bản sửa lỗi ở đâu và chúng có thể trông như thế nào? Chỉ có cách khắc phục là tất cả các Trình duyệt trên tất cả các biểu đồ có liên quan đều được triển khai TLS 1.1 hoặc 1.2. Tuy nhiên, tôi không tin điều này sẽ xảy ra đối với các bản đồ kế thừa như thế nào.

Vì vậy, bây giờ tôi chỉ thấy RC4 là một công việc vì hầu hết các nhà phát triển SW đã bỏ lỡ để thực hiện các tiêu chuẩn TLS mới nhất trong quá khứ và bây giờ chúng ta bị cuốn vào tình huống như hiện tại.

2
Jui

Cập nhật 2016 qua SSL Labs:

Bạn nên chủ yếu dựa vào các bộ AEAD cung cấp xác thực mạnh và trao đổi khóa, bảo mật chuyển tiếp và mã hóa ít nhất 128 bit. Một số bộ khác, bộ yếu hơn vẫn có thể được hỗ trợ, miễn là chúng chỉ được đàm phán với các khách hàng cũ không hỗ trợ gì tốt hơn.

Có một số nguyên thủy mã hóa lỗi thời cần phải tránh:

Các bộ Diffie-Hellman (ADH) ẩn danh không cung cấp xác thực.

  • Bộ mật mã NULL không cung cấp mã hóa.
  • Các bộ mật mã xuất khẩu không an toàn khi được đàm phán trong một kết nối, nhưng chúng cũng có thể được sử dụng để chống lại một máy chủ thích các bộ mạnh hơn (cuộc tấn công FREAK).
  • Các bộ có mật mã yếu (thường là 40 và 56 bit) sử dụng mã hóa có thể dễ dàng bị phá vỡ.
  • RC4 không an toàn.
  • 3DES chậm và yếu.

Sử dụng cấu hình bộ sau, được thiết kế cho cả khóa RSA và ECDSA, làm điểm bắt đầu của bạn:

ECDHE-ECDSA-AES128-GCM-SHA256
[.__.] ECDHE-ECDSA-AES256-GCM-SHA384
[.__.] ECDHE-ECDSA-AES128-SHA
[.__.] ECDHE-ECDSA-AES256-SHA
[.__.] ECDHE-ECDSA-AES128-SHA256
[.__.] ECDHE-ECDSA-AES256-SHA384
[.__.] ECDHE-RSA-AES128-GCM-SHA256
[.__.] ECDHE-RSA-AES256-GCM-SHA384
[.__.] ECDHE-RSA-AES128-SHA
[.__.] ECDHE-RSA-AES256-SHA
[.__.] ECDHE-RSA-AES128-SHA256
[.__.] ECDHE-RSA-AES256-SHA384
[.__.] DHE-RSA-AES128-GCM-SHA256
[.__.] DHE-RSA-AES256-GCM-SHA384
[.__.] DHE-RSA-AES128-SHA
[.__.] DHE-RSA-AES256-SHA
[.__.] DHE-RSA-AES128-SHA256
[.__.] DHE-RSA-AES256-SHA256
[.__.] EDH-RSA-DES-CBC3-SHA

Lưu ý Cấu hình ví dụ này sử dụng tên bộ không chuẩn theo yêu cầu của OpenSSL. Để triển khai trong các môi trường khác (ví dụ: IIS), bạn sẽ cần sử dụng tên bộ TLS tiêu chuẩn.

Tham khảo: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-codes-suites

1
bhushan5640

Trước tiên, hãy nhìn vào mật mã bất chấp cuộc tấn công BEAST.

Tôi khuyên bạn chỉ nên sử dụng các mật mã 'hiện tại' với các phím mạnh và không hỗ trợ các mật mã lịch sử mà không ai sử dụng. Vì vậy, không có RC4 chẳng hạn. Ngoài ra, tôi khuyên bạn nên chống lại các mật mã cấp xuất khẩu, chúng có các khóa rất yếu để chính phủ Hoa Kỳ có thể phá vỡ chúng. Mặc dù tôi tin rằng việc xuất tiền điện tử cấp cao hơn không còn là bất hợp pháp, nhưng khái niệm này vẫn tồn tại trong cấu hình máy chủ của bạn. Cuối cùng, tránh các thuật toán băm có vấn đề lớn, như MD5.

Bây giờ cuộc tấn công BEAST .. rõ ràng, AES trong chế độ CBC như được sử dụng trong TLS 1.0 dễ bị tấn công phục hồi văn bản gốc đã chọn. mail.google.com bảo vệ điều này bằng cách nhanh chóng chuyển sang 128 bit RC4 trong tuần này. Nếu bạn rất lo lắng về cuộc tấn công này trong 2 tuần tới (như google sẽ có), bạn có thể áp dụng cách giải quyết tương tự. Trong các trường hợp khác, tôi chỉ cần chờ sửa chữa và định cấu hình mật mã của bạn mà không liên quan đến cuộc tấn công này.

0
chris

Bạn có thể tìm thấy một số cấu hình thú vị cho lựa chọn thuật toán SSL & Apache mạnh ở đây:

Trình tạo cấu hình SSL SSL https://mozilla.github.io/server-side-tls/ssl-config-generator/

Đề xuất 2019.02 cho các trình duyệt hiện đại là:

SSLCodesSuite ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-CHA -AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES128-SHA256: ECDHE-RSA-AES

có thể đọc được

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
0
amprantino