Puncte:0

Cum să dezactivați liniile în java.security pentru a evita javax.net.ssl.SSLHandshakeException?

drapel ng

Trebuie să dezactivez următoarele linii din java.securitate fișier (java 8 SE):

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

în ferestre

Imagine în Windows.

Calea Windows: Fișiere program\Java\jre1.8.0_301\lib\security\java.security

Scopul dezactivării acestor linii este de a evita următorul mesaj de eroare:

Eroare: javax.net.ssl.SSLHandshakeException: Niciun protocol adecvat 
(protocolul este dezactivat sau suitele de cifrare sunt inadecvate)

Și propunerea de soluție publicată Aici (care este de a comenta aceste rânduri).

Nu sunt sigur dacă introducerea unui comentariu la începutul rândului (#) le va dezactiva pentru ambele sisteme de operare. pentru că acest document oracol spune este //

oricare este folosit pentru a comenta rândurile, nici nu știu dacă este necesar să comentați toate cele 3 rânduri sau doar comentarea primei dezactivează toate cele 3. Exemplu:

Pe aici:

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

sau asa?

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

Întrebare:

Cum să comentați (dezactivați) rândurile anterioare în java.securitate fișier pe Windows și Linux pentru a evita „Eroare: javax.net.ssl.SSLHandshakeException”, sau cineva să-mi explice dacă există o altă soluție, diferită de cea publicată

drapel in
Ce doriți să obțineți prin dezactivarea acestei linii? Poate că abordarea ta este pur și simplu greșită sau există o alternativă mai simplă.
drapel vn
Activarea acestor algoritmi deteriorați va avea un impact semnificativ asupra securității.
acgbox avatar
drapel ng
Știu și mulțumesc pentru clarificare, totuși întrebarea nu este legată de impactul de securitate pe care îl poate provoca dezactivarea acestor linii. Întrebarea este legată doar de „cum să dezactivați corect aceste linii pentru Windows și Linux”
dave_thompson_085 avatar
drapel jp
**Da, caracterul de comentariu este `#` pe toate sistemele.** Documentul pe care îl legați este despre fișierele de _politică_ de securitate, pentru SecurityManager (conceput inițial pentru applet-uri și acum puțin utilizat); java.security nu este un fișier de politică de securitate. Rețineți ca o alternativă la modificarea JRE/lib/security/java.security care afectează toate JVM-urile, puteți seta _system property_ `java.security.properties` să trimită către un fișier diferit (modificat) separat pentru fiecare/orice JVM, de ex. cu `-D` pe linia de comandă, sau puteți apela `Security.setProperty()` în codul dvs. suficient de aproape de început.
acgbox avatar
drapel ng
@dave_thompson_085 vă rugăm să postați acest răspuns pentru a-l selecta drept corect. si publica randurile exemplului pe care l-am dat, comentat, pentru ca nu stiu daca se comenteaza primul rand sau cele 3. multumesc pentru clarificare
Puncte:1
drapel jp

Da, caracterul de comentariu este # pe toate sistemele. Pagina web pe care o legați este despre fișierele cu politici de securitate, pentru SecurityManager (conceput inițial pentru applet-uri și acum puțin utilizat); java.security nu este un fișier de politică de securitate.

Da, faceți toate cele 3 rânduri. Sintaxa de continuare (backslash-eol) funcționează numai pe liniile necomentate, așa că pentru a comenta un articol continuat pe mai multe linii (fizice), comentați fiecare linie.

Cu toate acestea, deoarece acum clarificați că eroarea se află pe protocoale, ar fi mai sigur să ștergeți doar protocoalele care ofensează (aproape sigur TLSv1(.0) și/sau TLSv1.1 -- SSLv3 a fost dezactivat din 8u31 în 2015, după ce a fost spart catastrofal de POODLE) și lăsați restul.

Din întâmplare, încercați să utilizați o versiune veche de javamail? A existat o caracteristică (greșită) pentru o perioadă care a stabilit implicit modul securizat la TLSv1(.0) (numai) și a declanșat acest simptom când au apărut 8u291 și alte câteva versiuni; avem mai multe Q-uri existente despre asta, doar căutați „javamail no appropriate protocol”. În timp ce eliminați sau reduceți setarea disabledAlgorithms (sau regresați sub 8u291) va permite clientului să atentat, încercare o conexiune TLS1.0, multe servere astăzi nu o vor accepta deoarece TLS1.0 este considerat întrerupt; asta e De ce Java este acum schimbat pentru a-l dezactiva implicit. În acest caz, ar fi mai bine să actualizați javamail sau pentru a configura în mod explicit mail.{smtp,imap,pop3}.ssl.protocols la o valoare potrivită astăzi probabil TLSv1.2,TLSv1.3.

(Altele) Alternative: în general, în loc să schimbați lucrurile în JRE/lib/security/java.security, care afectează toate JVM-urile, puteți seta proprietatea sistemului java.security.properties pentru a indica un fișier diferit (modificat) separat pentru fiecare/orice JVM, de ex. cu -D pe linia de comandă sau puteți apela Security.setProperty() în codul dvs. suficient de aproape de început.

acgbox avatar
drapel ng
câteva lucruri: Răspunsul tău răspunde la întrebarea mea, dar parțial sau incomplet (Nu este javamail, ci un derivat openbravo numit unicenta opos). Și aș dori dacă ați putea extinde ultima parte „(Alte) alternative” cu un exemplu de configurare, deoarece nu găsesc fișierul `java.security.properties` în folderul java. Mulțumesc
dave_thompson_085 avatar
drapel jp
@acgbox: `java.security.properties` nu este un nume de fișier. După cum am spus, este o _proprietate de sistem_ a cărei _valoare_ poate fi calea (formal URL) a unui fișier pe care îl creați, care poate fi orice nume în orice locație pe care o considerați adecvată. Acesta este _descris_ în partea de sus a fișierului java.security; uitați-vă acolo, dar rețineți că arată doar modul de bază de setare a proprietății sistemului cu `-D`, în timp ce în unele medii există și alte moduri, de unde „de ex.”.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.