안녕하세요
사내에서 쓰는 사이트 중 일부가 TLS 1.0, 1.1 을 사용하고 있습니다
(JDK 1.6을 쓰고있는 사이트인데, 해당 버전은 1.0과 1.1이 필요하더군요..)
마음같아선 취약TLS 쓰는 사이트, 1.2만 쓰는 사이트 나누고
1.0/1.1 로 유입되는 NLB, 1.2로 유입되는 NLB로 구분하여 취약 TLS가 불필요한 사이트는 분리하고 싶지만..
전체 사이트 검수 및 비용 공수 때문에 해당 방법도 불가한 상황입니다 (AWS 사용 중)
더군다나, 서버 한대에서 여러 사이트를 굴리고 있는 실정이라.. 서버별로 TLS 나누는 것도 불가합니다
네트워크단, 서버단에서 해결이 불가하기에
어플리케이션단에서 조치하려 하는데,
1. 어플리케이션단에서 TLS 1.0, 1.1을 제거하는 방법이 있을까요?
2. TLS 1.0, 1.1 쓰는 사이트라도 어느정도 보완을 하고 싶은데 어플리케이션단에서 리스크를 줄일 방법이 있을까요?
사이트별로 웹와스는 각각 쓰기 때문에, 해당 사이트의 웹/와스를 수정한다 해서 다른 사이트에 영향은 가지 않습니다.
8개의 답변이 있습니다.
오래되고 안전하지 않은 TLS 버전(1.0 및 1.1) 문제를 해결하려면 특히 JDK 1.6에서 실행되는 애플리케이션을 처리할 때 다각적인 접근 방식이 필요합니다.
애플리케이션 수준에서 위험을 관리하고 완화하기 위한 방안으로 참고해보세요.
1.각 사이트가 자체 web/was(웹/애플리케이션 서버)를 사용한다고 언급했으므로 이를 개별적으로 구성할 수 방법은, 가능하다면 Java 버전을 JDK 1.7 이상으로 업데이트하세요. JDK 1.6은 오래되어 더 이상 지원되지 않으며 많은 보안 수정 사항이 부족합니다.
JDK 1.6의 경우 최신 JDK와 동일한 수준의 지원 및 유연성이 없으므로 TLS 버전을 프로그래밍 방식으로 구성해야 할 수도 있습니다.
2.레거시 요구 사항으로 인해 TLS 1.0 또는 1.1을 지원해야 하는 경우,
TLS 1.0 및 1.1에는 가장 강력한 암호화 제품군만 활성화되어 있는지 확인하십시오. 이는 웹/was에 따라 server.xml 또는 ssl.conf에서 구성할 수 있습니다.
Tomcat의 예:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
type="RSA" />
<Cipher>SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>
</SSLHostConfig></Connector>
다른 취약점을 완화하려면 HTTP 헤더로 보안을 강화하세요.
■HSTS(엄격한 전송 보안): 브라우저가 HTTPS를 통해서만 서버와 통신하도록 합니다.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
■콘텐츠 보안 정책(CSP): XSS 공격을 방지하는 데 도움이 됩니다.
Content-Security-Policy: default-src 'self'
AWS 환경에는 다음과 같은 추가 옵션이 있을 수 있습니다.
- AWS WAF(웹 애플리케이션 방화벽) 사용
AWS WAF는 일반적인 웹 공격으로부터 애플리케이션을 보호하는 데 도움이 됩니다.
- AWS 인증서 관리자
AWS Certificate Manager를 사용하면 가장 안전한 프로토콜과 암호가 사용되도록 SSL/TLS 인증서를 프로비저닝, 관리 및 배포할 수 있습니다.
- 애플리케이션 로드 밸런서(ALB) 구성
비용 문제에 대해 언급했지만 ALB를 사용하면 SSL 종료를 오프로드하고 최신 TLS 프로토콜 및 암호를 적용할 수 있습니다.
요약하면,
1.Java 업그레이드: 가능하다면 JDK 1.7+로 이동하세요.
2.사용자 정의 SSL/TLS 구성: JDK 1.6의 경우 사용자 정의 SSLSocketFactory 또는 시스템 속성을 사용하여 TLS 1.2를 적용합니다.
3.강력한 암호화 제품군: TLS 1.0/1.1에는 강력한 암호화 제품군만 활성화되어 있는지 확인하세요.
4.보안 헤더: HSTS, CSP 및 기타 보안 헤더를 구현합니다.
5.애플리케이션 보안: 애플리케이션 수준에서 강력한 보안 관행을 시행합니다.
6.AWS 개선 사항: AWS WAF, 인증서 관리자를 사용하고 SSL 종료를 위해 ALB를 고려합니다.
이렇게 하면 애플리케이션의 보안을 강화하고 이전 TLS 버전 사용과 관련된 위험을 완화할 수 있습니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입백업 후 업그레이드를 진행 해 보시는걸 추천드립니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입TLS 1.2 이하 버전이 걸리는게 많더라구요.
저희도 이런저런 이유로 버티다가 올렸습니다.
TLS 1.0, 1.0도 문제이지만 JDK 1.6도 많이 낮은편입니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입당사 개발담당자들에 문의한 결과 만약 업그레이드를 하지 않고 사용시 문제가 발생할 수 있어, 자신들도 번거롭지만 대부분 업그레이드를 해서 사용한다고 합니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입업그레이드 하시는제 좋을듯합니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입해당 내용은 L4/L7스위치에서 SSL Offloading 기능으로 해결할수 있을거에요.
장비를 들이시던가, 서버가 AWS에 있는거면 거기서도 제공되는 서비스가 있습니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입조금 비용이 발생하더라도 향후를 위해서는 Version 업 하는 것이 좋을 듯 싶네요.
보안 적인 문제도 크고, 나중에는 웹페이지에서 지원도 안되는 경우도 있습니다.
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입JDK 버전을 올리고, TLS도 상위 버전을 사용하는게 좋지 않를까요..?
JDK 버전 업으로 호환성 문제 발생하는 프로그램이 있다면 프로그램 소스를 수정, 재 컴파일해서 호환성을 맞춰주는 것이 근본적인 대처 방안이 되지 않을까요..?
댓글 남기기
답변을 작성 하시려면 로그인이 필요합니다.
로그인 회원가입