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/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/
Foi de grande ajuda!! Valeu demais cara!