Mostrando postagens com marcador Segurança. Mostrar todas as postagens
Mostrando postagens com marcador Segurança. Mostrar todas as postagens

quarta-feira, 8 de setembro de 2021

🔍 Diagnosticando TLS, SSL e HTTPS em Aplicações Java

Diagnosticando TLS, SSL e HTTPS

Ao construir aplicações interconectadas, desenvolvedores frequentemente interagem com protocolos habilitados para TLS, como HTTPS. Com a recente ênfase em comunicações criptografadas, este conteúdo aborda a forma como o JDK evolui em relação a protocolos, algoritmos e alterações, bem como alguns diagnósticos avançados para entender melhor conexões TLS como HTTPS.

A maioria dos desenvolvedores não precisará fazer esse nível de diagnóstico no processo de escrita ou execução de aplicações. No entanto, se necessário, as informações a seguir devem fornecer base suficiente para entender o que está acontecendo dentro de conexões seguras.


Evolução de protocolos e algoritmos

Nos últimos 15 anos, a plataforma Java evoluiu por meio do Java Community Process, onde empresas, organizações e indivíduos dedicados desenvolvem e votam em especificações para determinar o que compõe a Plataforma Java. Grande parte dos esforços está centrada na compatibilidade, como o TCK, garantindo que diferentes implementações sejam compatíveis entre si e que os desenvolvedores possam prever como suas aplicações serão executadas. Opções padrão críticas (como o protocolo TLS) não são alteradas dentro de versões menores.

A tabela a seguir descreve os protocolos e algoritmos suportados em cada versão do JDK:

JDK 8 (Março 2014 - presente) JDK 7 (Julho 2011 - presente) JDK 6 (2006 até fim das atualizações públicas 2013)
Protocolos TLS: TLSv1.2 (padrão)
TLSv1.1
TLSv1
SSLv3
Protocolos TLS: TLSv1.2
TLSv1.1
TLSv1 (padrão)
SSLv3
Protocolos TLS: TLSv1.2 (atualização 111+)
TLSv1.1 (atualização 111+)
TLSv1 (padrão)
SSLv3
Cifras JSSE: Cifras no JDK 8 Cifras JSSE: Cifras no JDK 7 Cifras JSSE: Cifras no JDK 6

📝 Código Java de exemplo para fazer uma conexão HTTPS

Fazer uma conexão HTTPS em Java é relativamente simples. O código é apresentado com foco no ajuste e na compreensão das capacidades subjacentes.

Código de back-end de exemplo para fazer uma conexão SSL:

final URL url = new URL("https://example.com");
try(final InputStream in = url.openStream()){
  //…
}

A conexão também pode ser ajustada através de um cast:

final HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
//opera em conn
conn.connect();
try(final InputStream in = conn.getInputStream()){
  //…
}

Exemplo: Página "View My Client" do Qualys SSL Labs

O Qualys SSL Labs mantém uma coleção de ferramentas úteis para entender conexões SSL/TLS. Uma em particular é a página "View My Client", que exibe informações sobre a conexão do cliente. Ao integrar com essa página, é possível controlar a implementação enquanto se usam diferentes parâmetros de ajuste do Java.

Para testar o ajuste de parâmetros, foi implementada uma pequena aplicação JavaFX em JavaScript. Ela exibe essa página em um WebView, mostrando informações sobre a conexão cliente SSL/TLS subjacente do Java. O código pode ser encontrado no apêndice.


🔧 Parâmetros de ajuste do JSSE

Ao diagnosticar problemas relacionados a TLS, há várias propriedades do sistema úteis. Elas geralmente são abordadas em suas seções relevantes do JSSE, mas esta coleção única pode ajudar quem busca entender a flexibilidade da implementação do Java ou diagnosticar detalhes de conexão.

Parâmetro Descrição
javax.net.debug Imprime detalhes de depuração para conexões feitas.
Exemplo: -Djavax.net.debug=all ou -Djavax.net.debug=ssl:handshake:verbose
https.protocols Controla a versão do protocolo usada por clientes Java que obtêm conexões https através do uso da classe HttpsURLConnection ou via operações URL.openStream(). Para versões mais antigas, isso pode atualizar o padrão, caso seu cliente Java 7 queira usar TLS 1.2 como padrão.
Exemplo: -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2
Para protocolos não HTTP, isso pode ser controlado através do SSLContext do SocketFactory.
jdk.tls.client.protocols Controla a implementação TLS subjacente da plataforma. Mais informações estão disponíveis no Guia de Referência do JSSE.
Exemplo: -Djdk.tls.client.protocols=TLSv1.1,TLSv1.2
Disponível em todas as versões do JDK 8, ou após Java 7 update 95 (Janeiro 2016) e Java 6 update 121 (Julho 2016).
http.agent Ao iniciar conexões, o Java aplica isso como sua string de agente do usuário. Modificar isso resolve casos onde a parte receptora responde de forma diferente com base no agente do usuário.
Exemplo: -Dhttp.agent=“agente conhecido”
java.net.useSystemProxies Usa detalhes de proxy do próprio sistema operacional.
Exemplo: -Djava.net.useSystemProxies=true
http.proxyHost
http.proxyPort
A conexão de proxy a ser usada para conexões HTTP.
Exemplo: -Dhttp.proxyHost=proxy.exemplo.com -Dhttp.proxyPort=8080
https.proxyHost
https.proxyPort
O mesmo que acima, exceto que a configuração é separada entre HTTP e HTTPS.
http.proxyUser
http.proxyPassword
https.proxyUser
https.proxyPassword
Credenciais baseadas em senha para os proxies acima.

🔎 Exemplo de diagnóstico de um problema

Ao fazer uma conexão HTTPS, suponha que o cliente lançou a seguinte exceção devido a um handshake falho com o servidor:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

SSLHandshakeException é uma subclasse de IOException, então não é necessário capturá-la explicitamente. A maioria dos desenvolvedores não precisará de uma captura explícita, mas isso pode ajudar a diagnosticar mais facilmente a causa de qualquer IOException.

Ao aplicar a propriedade -Djavax.net.debug=all, a falha associada a esta SSLHandshakeException apareceria logo após a negociação de algoritmo nos logs.

JDK 7 (falha em algoritmo não suportado) JDK 8 (funciona bem)
Cipher Suites: […Lista longa de cifras…]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {…}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [host_name: HOST]
main, WRITE: TLSv1 Handshake, length = 168
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Cipher Suites: […Lista longa de cifras…]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {…}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: …
Extension server_name, server_name: [type=host_name (0), value=HOST]
main, WRITE: TLSv1.2 Handshake, length = 226
main, READ: TLSv1.2 Handshake, length = 89
*** ServerHello, TLSv1.2
RandomCookie: GMT: -1809079139 bytes = { …}
Session ID: {…}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
%% Initialized: [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
** TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
main, READ: TLSv1.2 Handshake, length = 2308

No caso acima, a falha ocorreu durante o handshake. A causa mais provável para isso é o suporte de algoritmo. O JDK fornece um pacote separado chamado JCE Força Ilimitada, projetado para adicionar suporte a algoritmos mais fortes do que o disponível por padrão. O Qualys SSL Labs fornece um teste de servidor SSL diferente que enumerará quais algoritmos um servidor suporta.


Adicionando algoritmos mais fortes: JCE Força Ilimitada

Em um ambiente de alta segurança, uma forma de fortalecer os algoritmos no JDK é através dos arquivos de política JCE Força Ilimitada. Neste caso específico, substituir esses arquivos de política dentro do JDK 7 permite que ele use as variantes mais fortes dos algoritmos existentes e se conecte com sucesso.


Apêndice

O código a seguir abrirá a página "View My Client" do Qualys SSL Labs dentro de um cliente Java. Para testar configurações, execute assim:

jjs -fx viewmyclient.js
jjs -fx -Dhttps.protocols=TLSv1 viewmyclient.js
var Scene = javafx.scene.Scene;
var WebView = javafx.scene.web.WebView;
var browser = new WebView();
browser.getEngine().load("https://ssllabs.com/ssltest/viewMyClient.html");
$STAGE.scene = new Scene(browser);
$STAGE.show();

🔒 Mantendo os Usuários do Internet Explorer Atualizados e Seguros

🔒 Mantendo os Usuários Atualizados e Seguros

Existe um trabalho ativo em segurança do Java, com o objetivo importante de encontrar maneiras de remover versões antigas e inseguras de circulação. A recomendação é que os usuários de Java mantenham suas instalações JRE atualizadas com a linha de base de segurança mais recente por meio do recurso Java Auto Update.


🎯 Ações para Melhorar a Segurança

Há muito tempo, os usuários do Microsoft Windows têm conseguido melhorar a segurança de seu computador verificando versões antigas do Java e removendo-as usando a Java Uninstall Tool.

Recentemente, foi anunciado que o Internet Explorer em breve bloqueará controles ActiveX desatualizados. Esse recurso fornecerá aos usuários do Internet Explorer notificações quando as páginas da web tentarem carregar controles ActiveX desatualizados, como os controles Java ActiveX fornecidos por uma JRE abaixo da linha de base de segurança. Documentação e informações adicionais sobre como configurar e gerenciar esse novo recurso são fornecidas pela Microsoft.


⚙️ Diretrizes para Empresas e Desenvolvedores

Manter a segurança do Java é uma prioridade, e existe uma cooperação contínua com os parceiros para manter os usuários de Java atualizados e seguros em diferentes navegadores e sistemas operacionais.

As empresas que precisam manter uma JRE mais antiga para aplicativos legados ainda devem usar uma JRE atualizada instalada junto com a versão mais antiga e aproveitar a Funcionalidade Deployment Rule Set para limitar o acesso à JRE mais antiga apenas para aplicativos bem conhecidos.


Nota: Este conteúdo foi adaptado e traduzido para desenvolvedores brasileiros, com foco nas informações técnicas e de segurança.

🔒 Plano da Oracle para Remover a Confiança em Certificados TLS da Symantec no JDK

📅 Atualização 2019-01-25: Prazo Estendido para Certificados Gerenciados pela Apple

A confiança em certificados emitidos por duas subautoridades de certificação gerenciadas pela Apple será mantida por um período mais longo. As instruções sobre como reativar a confiança nas autoridades de certificação raiz afetadas foram atualizadas.


🔍 Introdução

O JDK da Oracle deixará de confiar em certificados TLS emitidos pela Symantec, alinhando-se a planos semelhantes anunciados recentemente por Google, Mozilla, Apple e Microsoft. A lista de certificados afetados inclui certificados das marcas GeoTrust, Thawte e VeriSign, que eram gerenciados pela Symantec.


⏰ Linha do Tempo da Mudança

A partir das versões de patch crítico planejadas para 16 de abril de 2019, todas as versões suportadas do JDK (12, 11, 8 e 7) começarão a remover a confiança em novos certificados de servidor TLS emitidos pelas autoridades de certificação afetadas.

📜 Certificados Existentes vs. Novos

  • Certificados emitidos antes de 16 de abril de 2019: Continuarão sendo confiáveis até sua data de expiração.
  • Certificados emitidos após 16 de abril de 2019: Serão rejeitados.

Informações sobre como substituir certificados Symantec por um certificado DigiCert estão disponíveis na página de suporte da DigiCert.


⚙️ Impacto Técnico e Como Funciona

As novas restrições serão aplicadas na implementação do JDK (o Provedor SunJSSE) da API Java Secure Socket Extension (JSSE). Uma sessão TLS não será negociada se a cadeia de certificados do servidor estiver ancorada por qualquer uma das Autoridades de Certificação listadas na tabela abaixo.

💻 Exemplo de Erro

Uma aplicação receberá uma exceção com uma mensagem indicando que a âncora de confiança não é confiável, por exemplo:

TLS Server certificate issued after 2019-04-16 and anchored by a distrusted legacy Symantec root CA: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US

🛠️ Contornando as Restrições (Medida Temporária)

Se necessário, é possível contornar as restrições comentando ou removendo "SYMANTEC_TLS" da propriedade de segurança jdk.security.caDistrustPolicies no arquivo de configuração java.security.

# Exemplo: Para desativar a política de desconfiança SYMANTEC_TLS
# jdk.security.caDistrustPolicies=SYMANTEC_TLS

Atenção: Esta é uma solução temporária. A ação correta é substituir o certificado.


📋 Autoridades de Certificação Raiz da Symantec Afetadas no JDK

A restrição será imposta aos seguintes certificados raiz da Symantec incluídos no JDK:

Nome Distinto (Distinguished Name)Imprensa Digital (Fingerprint) SHA-256
CN=GeoTrust Global CA, O=GeoTrust Inc., C=USFF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A
CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US37:D5:10:06:C5:12:EA:AB:62:64:21:F1:EC:8C:92:01:3F:C5:F8:2A:E9:8E:E5:33:EB:46:19:B8:DE:B4:D0:6C
CN=GeoTrust Primary Certification Authority – G2, OU=(c) 2007 GeoTrust Inc. – For authorized use only, O=GeoTrust Inc., C=US5E:DB:7A:C4:3B:82:A0:6A:87:61:E8:D7:BE:49:79:EB:F2:61:1F:7D:D7:9B:F9:1C:1C:6B:56:6A:21:9E:D7:66
CN=GeoTrust Primary Certification Authority – G3, OU=(c) 2008 GeoTrust Inc. – For authorized use only, O=GeoTrust Inc., C=USB4:78:B8:12:25:0D:F8:78:63:5C:2A:A7:EC:7D:15:5E:AA:62:5E:E8:29:16:E2:CD:29:43:61:88:6C:D1:FB:D4
CN=GeoTrust Universal CA, O=GeoTrust Inc., C=USA0:45:9B:9F:63:B2:25:59:F5:FA:5D:4C:6D:B3:F9:F7:2F:F1:93:42:03:35:78:F0:73:BF:1D:1B:46:CB:B9:12
CN=thawte Primary Root CA, OU=”(c) 2006 thawte, Inc. – For authorized use only”, OU=Certification Services Division, O=”thawte, Inc.”, C=US8D:72:2F:81:A9:C1:13:C0:79:1D:F1:36:A2:96:6D:B2:6C:95:0A:97:1D:B4:6B:41:99:F4:EA:54:B7:8B:FB:9F
CN=thawte Primary Root CA – G2, OU=”(c) 2007 thawte, Inc. – For authorized use only”, O=”thawte, Inc.”, C=USA4:31:0D:50:AF:18:A6:44:71:90:37:2A:86:AF:AF:8B:95:1F:FB:43:1D:83:7F:1E:56:88:B4:59:71:ED:15:57
CN=thawte Primary Root CA – G3, OU=”(c) 2008 thawte, Inc. – For authorized use only”, OU=Certification Services Division, O=”thawte, Inc.”, C=US4B:03:F4:58:07:AD:70:F2:1B:FC:2C:AE:71:C9:FD:E4:60:4C:06:4C:F5:FF:B6:86:BA:E5:DB:AA:D7:FD:D3:4C
EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA3F:9F:27:D5:83:20:4B:9E:09:C8:A3:D2:06:6C:4B:57:D3:A2:47:9C:36:93:65:08:80:50:56:98:10:5D:BC:E9
OU=VeriSign Trust Network, OU=”(c) 1998 VeriSign, Inc. – For authorized use only”, OU=Class 2 Public Primary Certification Authority – G2, O=”VeriSign, Inc.”, C=US3A:43:E2:20:FE:7F:3E:A9:65:3D:1E:21:74:2E:AC:2B:75:C2:0F:D8:98:03:05:BC:50:2C:AF:8C:2D:9B:41:A1
OU=Class 3 Public Primary Certification Authority, O=”VeriSign, Inc.”, C=USA4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09:CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05
OU=VeriSign Trust Network, OU=”(c) 1998 VeriSign, Inc. – For authorized use only”, OU=Class 3 Public Primary Certification Authority – G2, O=”VeriSign, Inc.”, C=US83:CE:3C:12:29:68:8A:59:3D:48:5F:81:97:3C:0F:91:95:43:1E:DA:37:CC:5E:36:43:0E:79:C7:A8:88:63:8B
CN=VeriSign Class 3 Public Primary Certification Authority – G3, OU=”(c) 1999 VeriSign, Inc. – For authorized use only”, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=USEB:04:CF:5E:B1:F3:9A:FA:76:2F:2B:B1:20:F2:96:CB:A5:20:C1:B9:7D:B1:58:95:65:B8:1C:B9:A1:7B:72:44
CN=VeriSign Class 3 Public Primary Certification Authority – G4, OU=”(c) 2007 VeriSign, Inc. – For authorized use only”, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US69:DD:D7:EA:90:BB:57:C9:3E:13:5D:C8:5E:A6:FC:D5:48:0B:60:32:39:BD:C4:54:FC:75:8B:2A:26:CF:7F:79
CN=VeriSign Class 3 Public Primary Certification Authority – G5, OU=”(c) 2006 VeriSign, Inc. – For authorized use only”, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US9A:CF:AB:7E:43:C8:D8:80:D0:6B:26:2A:94:DE:EE:E4:B4:65:99:89:C3:D0:CA:F1:9B:AF:64:05:E4:1A:B7:DF
CN=VeriSign Universal Root Certification Authority, OU=”(c) 2008 VeriSign, Inc. – For authorized use only”, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US23:99:56:11:27:A5:71:25:DE:8C:EF:EA:61:0D:DF:2F:A0:78:B5:C8:06:7F:4E:82:82:90:BF:B8:60:E8:4B:3C

Se você possui um certificado de servidor TLS emitido por uma das ACs acima, deve ter recebido uma mensagem da DigiCert com informações sobre a substituição desse certificado, sem custo.


🍏 Exceção: Certificados Gerenciados pela Apple

Certificados emitidos por duas autoridades de certificação subordinadas gerenciadas pela Apple, identificadas abaixo, continuarão a ser confiáveis desde que emitidos em ou antes de 31 de dezembro de 2019.

Nome Distinto (Distinguished Name)Imprensa Digital (Fingerprint) SHA-256Data de Desconfiança
CN=Apple IST CA 2 – G1, OU=Certification Authority, O=Apple Inc., C=USAC:2B:92:2E:CF:D5:E0:17:11:77:2F:EA:8E:D3:72:DE:9D:1E:22:45:FC:E3:F5:7A:9C:DB:EC:77:29:6A:42:4B2019-12-31
CN=Apple IST CA 8 – G1, OU=Certification Authority, O=Apple Inc., C=USA4:FE:7C:7F:15:15:5F:3F:0A:EF:7A:AA:83:CF:6E:06:DE:B9:7C:A3:F9:09:DF:92:0A:C1:49:08:82:D4:88:ED2019-12-31

🔧 Como Verificar seus Certificados

É possível usar a utilitário keytool do JDK para imprimir detalhes da cadeia de certificados, da seguinte forma:

keytool -v -list -alias <seu_alias_de_servidor> -keystore <seu_arquivo_de_keystore>

Se algum dos certificados na cadeia for emitido por uma das autoridades de certificação raiz na tabela acima e aparecer na saída, será necessário atualizar o certificado ou entrar em contato com a organização que gerencia o servidor, se não for o seu.


✅ Próximos Passos e Ação Recomendada

  1. Verifique a origem dos certificados TLS usados em suas aplicações e servidores.
  2. Substitua quaisquer certificados de servidor TLS emitidos pelas autoridades de certificação listadas, preferencialmente por um fornecedor diferente (como DigiCert).
  3. Teste a nova configuração em um ambiente de homologação.
  4. Planeje a implantação antes da data limite de 16 de abril de 2019 para evitar interrupções.

Manter a segurança da infraestrutura de certificados é essencial para a confiança na internet e a proteção de dados.

🚨 Lançamentos Previstos do Oracle Java SE 7u72 PSU e 8u25

🚀 Próximo Oracle Java SE 7u72 PSU

Está previsto para 14 de outubro o lançamento da atualização de patch crítico (CPU), conforme o cronograma regular para o Oracle Java SE.


🆕 Oracle Java SE 8u25

Para o Oracle Java SE 8, a versão será a 8u25. Agora, há um incentivo para que todos os usuários de Java façam o download e utilizem a versão de atualização mais recente do Java SE 8. Com este lançamento, o Java SE 8 está pronto para se tornar a versão padrão no Java.com, e, como mencionado anteriormente, o processo de atualização automática dos usuários para o Java SE 8 terá início no começo de 2015.


⚙️ Oracle Java SE 7: Duas Versões, Públicos Diferentes

Para o Oracle Java SE 7, haverá dois lançamentos voltados para públicos diferentes:

  • Oracle Java SE 7u71: É a CPU regular, contendo apenas correções de segurança. Esta é a atualização indicada para a maioria dos usuários.
  • Oracle Java SE 7u72 (PSU): Disponível separadamente para desenvolvedores e usuários que necessitam de melhorias adicionais que não são de segurança ou para testar funcionalidades atualizadas. Recomenda-se o uso da 7u72 se você estiver enfrentando algum dos problemas específicos mencionados em suas notas de versão, e também como parte de seus ciclos de garantia de qualidade. Essas melhorias e funcionalidades estão planejadas para serem incluídas como parte da próxima CPU programada para janeiro de 2015.

🔍 Para Mais Detalhes

Para obter informações mais detalhadas sobre a diferença entre CPU e PSU, consulte o artigo "Java CPU and PSU Releases Explained" disponível na OTN.

🔒 JDK 8 passará a usar TLS 1.2 como padrão

🚀 O Futuro da Segurança no JDK 8

Uma mudança importante foi anunciada para o JDK 8: a partir de uma atualização futura, o protocolo TLS (Transport Layer Security) 1.2 será habilitado por padrão para conexões cliente.


🔍 Por que essa mudança é importante?

O TLS é um protocolo fundamental para a segurança da comunicação na internet, protegendo dados transmitidos entre aplicações. Atualmente, o JDK 8 usa TLS 1.0 como padrão, uma versão mais antiga e considerada menos segura frente a vulnerabilidades modernas.

A transição para o TLS 1.2 como padrão reforça significativamente a segurança das aplicações Java, alinhando-se com as melhores práticas e os padrões atuais da indústria.


⚙️ O que muda exatamente?

A alteração principal está no valor padrão da propriedade de sistema jdk.tls.client.protocols. Quando essa propriedade não estiver definida, o JDK passará a negociar conexões usando TLS 1.2 por padrão.

O comportamento para conexões de servidor (onde o JDK atua como servidor TLS) permanecerá inalterado.


⚠️ Impacto e Compatibilidade

A maioria dos servidores e serviços modernos já suportam TLS 1.2, portanto, o impacto para a maioria dos usuários deve ser mínimo. No entanto, é importante estar ciente de cenários onde a compatibilidade pode ser afetada:

  • Conectando-se a servidores legados: Aplicações que precisam se comunicar com servidores muito antigos que suportam apenas TLS 1.0 ou 1.1 podem encontrar falhas de conexão.
  • Testes e Desenvolvimento: Ambientes de teste que utilizam servidores com suporte limitado a TLS podem precisar de ajustes.

🛠️ Gerenciando a Mudança e Solucionando Problemas

Para garantir uma transição suave, é possível gerenciar explicitamente os protocolos usados.

1. Verificando o protocolo atualmente em uso:
É possível depurar a conexão para ver qual versão do TLS está sendo negociada.

System.setProperty("javax.net.debug", "ssl:handshake");
// Sua lógica de conexão aqui...

2. Revertendo para o comportamento anterior (NÃO RECOMENDADO):
Se for absolutamente necessário conectar-se a um serviço legado, é possível redefinir o padrão para TLS 1.0 definindo a propriedade de sistema na linha de comando da JVM. Esta é uma solução temporária e compromete a segurança.

java -Djdk.tls.client.protocols="TLSv1" -jar MinhaAplicacao.jar

3. Especificando múltiplos protocolos (Abordagem Preferida):
A abordagem mais robusta é especificar explicitamente uma lista de protocolos suportados, permitindo o uso do TLS 1.2 mas mantendo a compatibilidade com versões anteriores se necessário. Isso pode ser feito programaticamente.

import javax.net.ssl.*;
import java.security.Security;
import java.util.Arrays;

SSLContext context = SSLContext.getInstance("TLS");
context.init(null, null, null);
SSLSocketFactory factory = context.getSocketFactory();
SSLSocket socket = (SSLSocket) factory.createSocket("host", port);

// Definir protocolos explicitamente
socket.setEnabledProtocols(new String[] {"TLSv1.2", "TLSv1.1", "TLSv1"});

🎯 Conclusão

A mudança para TLS 1.2 como padrão no JDK 8 é um passo importante para a segurança do ecossistema Java. Ela protege os usuários e suas aplicações contra ameaças conhecidas em versões mais antigas do TLS.

Desenvolvedores e administradores de sistema devem testar suas aplicações em ambientes que reflitam essa nova configuração padrão para identificar e resolver quaisquer problemas de compatibilidade com antecedência, priorizando sempre a manutenção da segurança.

🚀 Filtrando Dados de Serialização de Entrada – Um pouco da qualidade do JDK 9 disponível agora nas famílias de lançamento atuais

🚀 Filtrando Dados de Serialização de Entrada – Um pouco da qualidade do JDK 9 disponível agora

Uma das novas funcionalidades desenvolvidas para o JDK 9, a JEP 290: Filter Incoming Serialization Data (Filtrar Dados de Serialização de Entrada), foi retroportada para o JDK 8, 7 e 6.


A opção de filtrar dados de serialização de entrada adiciona mais uma camada de proteção e robustez à serialização de objetos. Ao usar o mecanismo de filtragem, os desenvolvedores podem restringir as classes que podem ser desserializadas por um aplicativo. Como a maioria dos recursos de segurança, este novo recurso não se destina a substituir as práticas atuais de codificação segura, mas a complementá-las.


🔄 Disponibilidade e Retroportes

O recurso está disponível nas versões de acesso antecipado do JDK 9, mas como havia o desejo de que os usuários das versões atuais também tivessem essa capacidade, ele já foi retroportado para as atualizações do JDK e JRE lançadas com a Atualização Crítica de Pacotes (Critical Patch Update) de janeiro de 2017 (8u121, 7u131 e 6u141). Consulte as notas de lançamento das versões correspondentes para obter mais informações.


💡 Por Que Este Filtro é Importante?

Implementar um filtro para dados de serialização de entrada é uma etapa proativa para reforçar a segurança de aplicações que dependem de desserialização. Ele age como um guardião, validando o que pode ser reconstruído a partir do fluxo de bytes recebido, ajudando a mitigar potenciais vetores de ataque.

🔐 Entendendo Porque Código Java Assinado Precisa ser Reassinarado Periodicamente, Mesmo com Carimbo de Tempo

🔐 Entendendo Porque Código Java Assinado Precisa ser Reassinarado Periodicamente, Mesmo com Carimbo de Tempo

🛡️ O Problema: Certificados Expiráveis


A base do problema está no fato de que os certificados de assinatura de código usados pelos desenvolvedores têm uma data de validade. Embora a tecnologia de carimbo de tempo (timestamping) seja projetada para provar que a assinatura foi aplicada quando o certificado ainda era válido, isso não resolve todos os problemas na prática.

Muitas vezes, as políticas de validação de certificados são configuradas para rejeitar qualquer coisa assinada com um certificado que não esteja atualmente válido – independentemente do carimbo de tempo. Isso significa que, uma vez que o certificado usado para assinar o código expira, a assinatura pode ser considerada inválida pelos sistemas de destino.

🔍 A Anatomia de uma Assinatura de Código Java


Quando um arquivo JAR é assinado, um hash criptográfico (resumo) do conteúdo é calculado e criptografado com a chave privada do assinante. Isso cria uma assinatura digital que é armazenada no arquivo JAR, junto com o certificado do assinante (que contém a chave pública correspondente).

O processo de verificação:

  1. Recalcula os hashes do conteúdo do JAR.
  2. Decifra a assinatura armazenada usando a chave pública do certificado do assinante.
  3. Compara os hashes. Se eles coincidirem, a integridade e a autenticidade são confirmadas.

O carimbo de tempo é um registro assinado por uma Autoridade de Carimbo de Tempo (TSA), atestando que a assinatura do código foi apresentada para carimbo de tempo em uma data/hora específica. Isso prova que a assinatura existia quando o certificado do assinante era válido.

⚙️ Como a Validação Pode Falhar


Imagine um certificado de assinatura de código válido de 1º de janeiro de 2020 a 31 de dezembro de 2022. Um desenvolvedor assina um JAR e obtém um carimbo de tempo válido em 1º de julho de 2022. Em teoria, este carimbo de tempo deveria permitir que a assinatura fosse considerada válida para sempre, pois prova que o certificado era válido no momento da assinatura.

No entanto, na prática, a validação ocorre em duas etapas principais:

// Exemplo conceitual do caminho de validação
1. Validação do certificado do assinante: O certificado ainda é confiável e válido (não revogado)?
2. Validação da assinatura do conteúdo: A assinatura corresponde ao conteúdo e foi carimbada no tempo?

A primeira etapa – a validação do próprio certificado – pode falhar depois que o certificado expira. Alguns validadores rigorosos podem recusar imediatamente qualquer cadeia de certificados que contenha um certificado expirado, sem considerar o carimbo de tempo. Outros, seguindo padrões como RFC 3161, podem aceitar o carimbo de tempo e considerar a assinatura válida.

🔄 O Processo de Reassinar


Para garantir a máxima compatibilidade e evitar falhas de validação devido a certificados expirados, é recomendado reassinar periodicamente o código com um certificado atual. Isso não é um "reparo" de uma assinatura quebrada, mas uma manutenção proativa.

O processo típico envolve:

  1. Obter um novo certificado de assinatura de código válido.
  2. Remover as assinaturas antigas do arquivo JAR.
  3. Aplicar uma nova assinatura com o certificado atual.
  4. Obter um novo carimbo de tempo para essa assinatura.

Isso efetivamente "renova" a vida útil da assinatura do código, garantindo que o certificado do assinante na cadeia de validação esteja sempre dentro de seu período de validade.

✅ Melhores Práticas e Conclusão


Para garantir que o código assinado permaneça válido e confiável ao longo do tempo:

  • Planeje a rotação de certificados: Monitore as datas de validade dos seus certificados de assinatura de código e planeje reassinar aplicativos antes que expirem.
  • Use carimbo de tempo sempre: Sempre utilize um serviço de carimbo de tempo confiável (TSA) ao assinar. Isso protege a validade a longo prazo da assinatura *dentro do período de validade do certificado* e é crucial para a rastreabilidade.
  • Entenda seu ambiente de validação: Considere onde seu código será executado. Ambientes com políticas de validação estritas (como alguns navegadores web ou gateways corporativos) são mais propensos a rejeitar certificados expirados, tornando a reassinatura periódica essencial.
  • Automatize quando possível: Incorpore a reassinatura em seus pipelines de CI/CD para distribuições de aplicativos de longa duração.

Em resumo, enquanto o carimbo de tempo é uma tecnologia crítica para preservar a validade de uma assinatura digital após a expiração do certificado, ele não é uma solução infalível devido à variação na implementação dos validadores. A reassinatura periódica com um certificado atual é a prática mais robusta para garantir que o código Java assinado continue sendo executado sem interrupções em todos os ambientes, mantendo a cadeia de confiança intacta.

terça-feira, 31 de agosto de 2021

🚀 Java Card 3.0.5 Platform Classic Edition: A Nova Versão Está Disponível!

🚀 A Plataforma Oracle Java Card 3, Classic Edition, Versão 3.0.5 Já Está Disponível

É com grande satisfação que anunciamos a disponibilidade geral da Oracle Java Card 3 Platform Classic Edition, versão 3.0.5. Esta é uma versão de manutenção que inclui correções de bugs, patches de segurança e aprimoramentos na documentação, mantendo a compatibilidade com versões anteriores.


🎯 Por Que Atualizar para a Versão 3.0.5?

A atualização para esta nova versão é altamente recomendada para todos os usuários. Ela fornece correções essenciais e patches de segurança que fortalecem a robustez e a proteção de aplicações e dispositivos. Manter-se atualizado garante a máxima estabilidade e segurança para suas implementações.


📦 O Que Há de Novo?

Esta versão 3.0.5 é uma release de Manutenção cumulativa. As principais áreas de foco incluem:

  • Correções de bugs gerais para melhorar a confiabilidade.
  • Aplicação de patches de segurança para proteger contra vulnerabilidades conhecidas.
  • Aprimoramentos e esclarecimentos na documentação para facilitar o desenvolvimento.

🔧 Recursos-Chave da Plataforma Java Card 3 Classic

A plataforma Java Card 3.0.5 Classic Edition continua oferecendo os sólidos fundamentos para desenvolvimento seguro:

  • Ambiente de Execução Confiável (TEE): Executa aplicações Java de forma isolada e segura em cartões inteligentes e dispositivos com recursos limitados.
  • Segurança Robusta: Fornece um modelo de segurança forte com verificação de bytecode, gerenciamento de memória segura e isolamento de applets.
  • Compatibilidade: Totalmente compatível com a versão anterior 3.0.4, permitindo uma migração suave.
  • Suporte a APIs Modernas: Inclui suporte a APIs de criptografia contemporâneas para atender aos requisitos de segurança atuais.

📥 Como Obter e Começar

A versão 3.0.5 da Oracle Java Card 3 Platform Classic Edition está disponível para download imediato. O pacote inclui o Kit de Desenvolvimento de Software (SDK), a Documentação da API e a Especificação de Runtime.

Para obter os binários e a documentação completa, visite o portal oficial de downloads. É necessário ter uma conta Oracle e aceitar o contrato de licença aplicável.


🛠️ Recursos para Desenvolvedores

Para auxiliar no desenvolvimento, a seguinte documentação está incluída no pacote de download:

  • Guia do Usuário da Plataforma Java Card 3
  • Especificações da API de Runtime
  • Documentação de Referência da API
  • Guia de Migração

Esses recursos fornecem toda a informação necessária para desenvolver, testar e depurar applets Java Card.


🔍 Acompanhando Problemas e Solicitações

O ciclo de desenvolvimento da plataforma Java Card valoriza o feedback da comunidade. Problemas identificados ou solicitações de aprimoramento para versões futuras podem ser relatados e acompanhados através do portal oficial de suporte.


✨ Conclusão

A Oracle Java Card 3 Platform Classic Edition 3.0.5 representa um passo importante na evolução contínua desta tecnologia crítica para segurança de dispositivos. Sua ênfase em correções de estabilidade e segurança a torna uma atualização essencial para todos os parceiros e desenvolvedores do ecossistema.

Explore os novos recursos, fortaleça a segurança de suas aplicações e continue inovando com Java Card!

🔒 JavaOne 2015: A Evolução da Plataforma Java Card

📱 Apresentação do JavaOne 2015

Na segunda-feira, 26 de outubro, foi apresentada a sessão CON2582 detalhando como os desenvolvedores podem utilizar as novas APIs e ferramentas da versão mais recente da plataforma Java Card Classic para desenvolver rapidamente aplicações seguras e certificáveis para smartcards e elementos seguros. A sessão também esboçou direções potenciais na tecnologia Java Card conforme ela se expande além dos fatores de forma tradicionais de smartcards para elementos seguros embarcados e componentes de hardware confiáveis para segurança da Internet das Coisas.


⏰ Detalhes da Sessão

Esta sessão ocorreu às 16:00 no Hilton—Continental Ballroom 7/8/9.


🔗 Para Mais Informações

Para mais informações, consulte os documentos mais recentes de API e ferramentas do Java Card localizados na página de documentação da Plataforma Java Card.