Điểm:0

Làm cách nào để tắt các dòng trong java.security để tránh javax.net.ssl.SSLHandshakeException?

lá cờ ng

Tôi cần phải vô hiệu hóa các dòng sau trong java.an ninh tệp (java 8 SE):

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
   bao gồm jdk.disabled.namedCurves

trong cửa sổ

Hình ảnh trong Windows.

Đường dẫn cửa sổ: Tệp chương trình\Java\jre1.8.0_301\lib\security\java.security

Mục đích của việc tắt các dòng này là để tránh thông báo lỗi sau:

Lỗi: javax.net.ssl.SSLHandshakeException: Không có giao thức thích hợp 
(giao thức bị vô hiệu hóa hoặc bộ mật mã không phù hợp)

Và đề xuất giải pháp được công bố đây (tức là để bình luận về những dòng này).

Tôi không chắc liệu việc đặt nhận xét ở đầu dòng (#) có vô hiệu hóa chúng cho cả hai hệ điều hành hay không. Bởi vì tài liệu tiên tri này nói là //

cái nào dùng để comment các dòng, mình cũng không biết có cần comment cả 3 dòng không hay chỉ comment dòng đầu tiên là vô hiệu hóa cả 3. Ví dụ:

cách này:

# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
   bao gồm jdk.disabled.namedCurves

hay cách đó?

# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
# DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
# bao gồm jdk.disabled.namedCurves

Câu hỏi:

Làm thế nào để bình luận (vô hiệu hóa) các dòng trước đó trong java.an ninh trên Windows và Linux để tránh "Lỗi: javax.net.ssl.SSLHandshakeException" hoặc ai đó giải thích cho tôi nếu có giải pháp khác, khác với giải pháp đã xuất bản

lá cờ in
Bạn muốn đạt được điều gì bằng cách vô hiệu hóa (các) dòng này? Có thể cách tiếp cận của bạn đơn giản là sai hoặc có một giải pháp thay thế đơn giản hơn.
lá cờ vn
Kích hoạt các thuật toán bị hỏng này sẽ có tác động bảo mật đáng kể.
acgbox avatar
lá cờ ng
Tôi biết và cảm ơn vì đã giải thích rõ ràng, tuy nhiên câu hỏi không liên quan đến tác động bảo mật mà việc vô hiệu hóa các dòng này có thể gây ra. Câu hỏi chỉ liên quan đến "làm thế nào để vô hiệu hóa các dòng này một cách chính xác cho windows và linux"
dave_thompson_085 avatar
lá cờ jp
**Có, ký tự nhận xét là `#` trên tất cả các hệ thống.** Tài liệu mà bạn liên kết là về các tệp _policy_ bảo mật, dành cho Trình quản lý bảo mật (ban đầu được thiết kế cho các applet và hiện ít được sử dụng); java.security không phải là tệp chính sách bảo mật. Lưu ý thay thế cho việc thay đổi JRE/lib/security/java.security ảnh hưởng đến tất cả các JVM, bạn có thể đặt _system property_ `java.security.properties` để trỏ đến một tệp (đã sửa đổi) khác riêng cho từng/bất kỳ JVM nào, ví dụ: bằng `-D` trên dòng lệnh hoặc bạn có thể gọi `Security.setProperty()` trong mã của mình ở gần đầu.
acgbox avatar
lá cờ ng
@dave_thompson_085 vui lòng đăng câu trả lời này để chọn câu trả lời đúng. và công bố các dòng của ví dụ mà tôi đã đưa ra, đã nhận xét, vì tôi không biết dòng đầu tiên hay dòng thứ 3 được nhận xét. Cảm ơn bạn đã làm rõ
Điểm:1
lá cờ jp

Có, ký tự nhận xét là # trên tất cả các hệ thống. Trang web bạn liên kết là về các tệp chính sách bảo mật, dành cho Trình quản lý bảo mật (ban đầu được thiết kế cho các applet và hiện ít được sử dụng); java.security không phải là tệp chính sách bảo mật.

Có làm cả 3 dòng. Cú pháp tiếp tục (dấu gạch chéo ngược-eol) chỉ hoạt động trên các dòng không có chú thích, vì vậy để chú thích một mục tiếp tục trên nhiều dòng (vật lý), hãy chú thích từng dòng.

Tuy nhiên, vì bây giờ bạn đã làm rõ lỗi là do các giao thức, sẽ an toàn hơn nếu chỉ xóa (các) giao thức vi phạm (gần như chắc chắn là TLSv1(.0) và/hoặc TLSv1.1 -- SSLv3 đã bị vô hiệu hóa kể từ 8u31 vào năm 2015 sau khi nó bị POODLE phá vỡ nghiêm trọng) và để lại phần còn lại.

Có phải bạn đang cố gắng sử dụng một phiên bản cũ của javamail không? Đã có một tính năng (sai) trong một thời gian mặc định chế độ bảo mật thành TLSv1(.0) (chỉ) và gây ra hiện tượng này khi 8u291 và một số phiên bản khác xuất hiện; chúng tôi có một số câu hỏi hiện có về nó, chỉ cần tìm kiếm "javamail không có giao thức thích hợp". Trong khi xóa hoặc giảm cài đặt Thuật toán bị vô hiệu hóa (hoặc hồi quy dưới 8u291) sẽ cho phép máy khách nỗ lực kết nối TLS1.0, nhiều máy chủ ngày nay sẽ không chấp nhận vì TLS1.0 được coi là bị hỏng; đó là tại sao Java hiện đã được thay đổi để tắt nó theo mặc định. Trong trường hợp này, tốt hơn hết là nâng cấp javamail hoặc để cấu hình rõ ràng thư.{smtp,imap,pop3}.ssl.protocols đến một giá trị phù hợp với ngày hôm nay có lẽ TLSv1.2,TLSv1.3.

(Khác) Các lựa chọn thay thế: nói chung thay vì thay đổi mọi thứ trong JRE/lib/security/java.security ảnh hưởng đến tất cả các JVM, bạn có thể đặt thuộc tính hệ thống java.security.properties để trỏ đến một tệp (đã sửa đổi) khác riêng biệt cho từng/bất kỳ JVM nào, ví dụ: với -D trên dòng lệnh, hoặc bạn có thể gọi Bảo mật.setProperty() trong mã của bạn đủ gần đầu.

acgbox avatar
lá cờ ng
một vài điều: Câu trả lời của bạn trả lời câu hỏi của tôi, nhưng một phần hoặc không đầy đủ (Đó không phải là javamail, mà là một công cụ phái sinh openbravo có tên là unicenta opos). Và tôi muốn nếu bạn có thể mở rộng phần cuối cùng "(Khác) Alternatives" với một ví dụ về cấu hình, bởi vì tôi không thể tìm thấy tệp `java.security.properties` trong thư mục java. Cảm ơn bạn
dave_thompson_085 avatar
lá cờ jp
@acgbox: `java.security.properties` không phải là tên tệp. Như tôi đã nói, đó là thuộc tính _system_ có _value_ có thể là tên đường dẫn (URL chính thức) của tệp bạn tạo, có thể là bất kỳ tên nào ở bất kỳ vị trí nào bạn cho là phù hợp. Đây là _descripted_ ở đầu tệp java.security; hãy xem ở đó, nhưng lưu ý rằng nó chỉ hiển thị cách cơ bản để thiết lập thuộc tính hệ thống bằng `-D` trong khi ở một số môi trường, có nhiều cách khác do đó là 'ví dụ:' của tôi.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.