Java – Liberando o TLSv1 no Java 11 ou superior

Em algumas situações não temos como atualizar um sistema legado e infelizmente podemos ter que nos comunicar atravéz de criptografias que estejam depreciadas. Exemplo:

Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]".

Se você estiver executando em um ambiente aberto, podemos simplismente encontrar o arquivo java.security na instalação do JRE que executará o software e basta só remover o algoritimo desejado da propertie: jdk.tls.disabledAlgorithms.

Se você estiver em uma imagem docker, podemos usar o sed para isso:

ps. o diretório ai é um exemplo! confira o seu.

RUN sed -i 's/ TLSv1, TLSv1.1,//' /etc/alternatives/jre/lib/security/java.security

Caso 2 (menos comun) – Supondo que o arquivo não exista dentro do diretório lib/security de sua JRE ou até mesmo o propertie jdk.tls.disabledAlgorithms não esteja configurado, podemos inclui-lo sem o TLSv1: (porém ainda mantendo alguns indesejados)

RUN echo "jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL" >> /etc/alternatives/jre/lib/security/java.security

Talvez seja interessante forçar o uso do arquivo java.security na inicialização do software incluindo o argumento -Djava.security.properties:

ENV JAVA_OPTIONS="-Djava.security.properties=/etc/alternatives/jre/lib/security/java.security"

Você pode habilitar o debug e ver o que está acontecendo também, basta adicionar no JAVA_OPTIONS a properties:

-Djava.security.debug=properties

Em alguns casos (dependendo da VM) podemos ter dois arquivos gerenciando o security, o seu e algum do sistema:

Exemplo coletado com o debug ativo: Na linha 2 é exibido que carregou nosso arquivo e na linha 4 o arquivo do sistema (ainda com o TLS desabilitado, veja na linha 5).

L1: exec java -Djava.security.debug=properties -XX:+ExitOnOutOfMemoryError -cp . -jar /deployments/app.jar
L2: properties: reading security properties file: /usr/lib/jvm/java-17-openjdk-17.0.2.0.8-4.el8_5.x86_64/conf/security/java.security
L3: properties: {jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, fips.pro....
L4: properties: reading system security properties file /etc/crypto-policies/back-ends/java.config
L5: properties: {jdk.jar.disabledAlgorithms=MD2, MD5, TLSv1.1, TLSv1, RSA keySize < 1024, DSA keySize < 1024, ...

Nesse caso basta tirarmos ele com o sed:

RUN sed -i 's/ TLSv1.1, TLSv1,//' /etc/crypto-policies/back-ends/java.config

Em alguns casos pode dar um outro problema de RSA keySize < 1024, já que incluimos um algoritimo inseguro, basta fazermos o mesmo procedimento com ele;

RUN sed -i 's/, RSA keySize < 2048//' /etc/crypto-policies/back-ends/java.config

Segue um exemplo de um Dockerfile do Java 17 usando uma imagem da redhat já com essa customização:

FROM registry.access.redhat.com/ubi8/ubi-minimal:8.3

ARG JAVA_PACKAGE=java-17-openjdk-headless
ARG RUN_JAVA_VERSION=1.3.8
ENV LANG='en_US.UTF-8' LANGUAGE='en_US:en'

RUN microdnf install curl ca-certificates ${JAVA_PACKAGE} tar gzip \
    && microdnf update \
    && microdnf clean all \
    && mkdir /deployments \
    && chown 1001 /deployments \
    && chmod "g+rwX" /deployments \
    && chown 1001:root /deployments \
    && curl https://repo1.maven.org/maven2/io/fabric8/run-java-sh/${RUN_JAVA_VERSION}/run-java-sh-${RUN_JAVA_VERSION}-sh.sh -o /deployments/run-java.sh \
    && chown 1001 /deployments/run-java.sh \
    && chmod 540 /deployments/run-java.sh \
    && echo "securerandom.source=file:/dev/urandom" >> /etc/alternatives/jre/lib/security/java.security

RUN sed -i 's/ TLSv1.1, TLSv1,//' /etc/crypto-policies/back-ends/java.config
RUN sed -i 's/, RSA keySize < 2048//' /etc/crypto-policies/back-ends/java.config

COPY /target/*.jar /deployments/app.jar

EXPOSE 8080
USER 1001

ENTRYPOINT [ "/deployments/run-java.sh" ]

Referências:

https://stackoverflow.com/questions/54634060/java-algorithm-constraints-check-failed-on-key-rsa-with-size-of-1024bits

https://stackoverflow.com/questions/65327349/java-security-properties-changes-not-applied

https://stackoverflow.com/questions/4521119/java-argument-to-specify-java-security-file-for-jvm

https://asyncstream.com/tutorials/java-tlsv10-not-accepted-by-client-preferences/

Help DEV – Analista desenvolvedor Java / Android https://helpdev.com.br/zarelli

Java – Liberando o TLSv1 no Java 11 ou superior

2 pensou em “Java – Liberando o TLSv1 no Java 11 ou superior

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Rolar para o topo