Início / server / Perguntas / 1093174
Accepted
acgbox
Asked: 2022-02-10 06:50:27 +0800 CST

Como desabilitar linhas em java.security para evitar javax.net.ssl.SSLHandshakeException?

  • 772

Preciso desabilitar as seguintes linhas no arquivo java.security (java 8 SE):

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

nas janelas

Imagem no Windows.

Caminho do Windows:Program Files\Java\jre1.8.0_301\lib\security\java.security

O objetivo de desabilitar essas linhas é evitar a seguinte mensagem de erro:

Error: javax.net.ssl.SSLHandshakeException: No appropriate protocol 
(protocol is disabled or cipher suites are inappropriate)

E a proposta de solução aqui publicada (que é comentar nestas linhas).

Não tenho certeza se colocar um comentário no início da linha (#) irá desativá-los para ambos os sistemas operacionais. Porque este documento do oráculo diz que é //

qualquer que seja usada para comentar as linhas, também não sei se é necessário comentar todas as 3 linhas, ou apenas comentar a primeira desabilita todas as 3. Exemplo:

Por aqui:

# 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

ou assim?

# 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

Pergunta:

Como comentar (desabilitar) as linhas anteriores no arquivo java.security no Windows e Linux para evitar "Erro: javax.net.ssl.SSLHandshakeException", ou alguém me explique se existe outra solução, diferente da publicada

windows java linux

1 respostas

  1. Best Answer

    Sim, o caractere de comentário é # em todos os sistemas. A página da Web que você vincula é sobre arquivos de política de segurança, para o SecurityManager (originalmente projetado para applets e agora pouco usado); java.security não é um arquivo de política de segurança.

    Sim, todas as 3 linhas. A sintaxe de continuação (barra invertida-eol) só funciona em linhas não comentadas, portanto, para comentar um item continuado em várias linhas (físicas), comente cada linha.

    No entanto, como agora você deixa claro que o erro está nos protocolos, seria mais seguro excluir apenas o(s) protocolo(s) incorreto(s) (quase certamente TLSv1(.0) e/ou TLSv1.1 -- SSLv3 foi desabilitado desde 8u31 em 2015 depois de ter sido catastroficamente quebrado pelo POODLE) e deixar o resto.

    Você por acaso está tentando usar uma versão antiga do javamail? Houve um (des)recurso por um tempo que padronizou o modo seguro para TLSv1(.0) (somente) e acionou esse sintoma quando 8u291 e várias outras versões foram lançadas; temos várias Qs existentes sobre isso, basta pesquisar "javamail sem protocolo apropriado". Embora a remoção ou redução da configuração disabledAlgorithms (ou regressão abaixo de 8u291) permita que o cliente tente uma conexão TLS1.0, muitos servidores hoje não a aceitarão porque o TLS1.0 é considerado quebrado; é por isso que o Java agora foi alterado para desativá-lo por padrão. Neste caso, seria melhor atualizar o javamail ou configurar explicitamente mail.{smtp,imap,pop3}.ssl.protocolspara um valor adequado hoje, provavelmente TLSv1.2,TLSv1.3.

    (Outras) Alternativas: em geral, em vez de alterar as coisas no JRE/lib/security/java.security que afeta todas as JVMs, você pode definir a propriedade do sistema java.security.propertiespara apontar para um arquivo diferente (modificado) separadamente para cada/qualquer JVM, por exemplo -D, na linha de comando , ou você pode chamar Security.setProperty()seu código suficientemente perto do início.

    • 1

relate perguntas