비슷한 맥락으로, 웹사이트의 보안 헤더를 스캔할 수 있는 SecurityHeaders와 TLS 설정을 검증하는 SSL Labs Test, 그리고 커맨드라인에서 사이트를 스캔할 수 있는 testssl.sh 같은 도구가 있음
인터넷에 접근할 수 없는 환경이나 자동화된 HTML 리포트 생성 시 유용함
내부 네트워크에서 스캔이 필요했는데, testssl.sh가 너무 느려서 직접 만든 스캐너 hello_tls를 사용함
병렬화와 옵션 비활성화에도 최소 20초가 걸렸는데, 새 도구는 60~100배 빠름
취약점 분석은 없지만, 설정 추출이 목적이었음
하지만 security headers 사이트에는 동의하지 않음
각 헤더는 기능이 다르고, 사이트 목적에 따라 적용하지 않아야 할 경우도 있음
예를 들어 CSP 헤더가 있어도 실제로는 무의미하게 설정된 경우가 많음
왜 아직도 “SSL”이라는 용어를 쓰는지 모르겠음
지난 10년간의 기술 발전을 잊은 것처럼 느껴짐
나도 “TLS”를 쓰지만 쉽지 않음
고객에게 TLS 인증서를 설정한다고 하면 “우린 SSL이 필요하다”고 걱정하는 경우가 많음
결국 인지도 문제임. 일반 사용자는 TLS를 모르고, 기업은 혼란을 피하려고 SSL을 계속 씀
Cloudflare의 SSL 페이지도 경로는 SSL이지만 내용은 TLS 중심이라 혼란스러움
SSL은 90년대 Netscape가 개발했고, 이후 TLS로 발전했음
Netscape Navigator가 Mozilla로 이어졌기 때문에 Mozilla가 여전히 SSL 용어를 많이 쓰는 것도 이해됨
지난 10년간의 기술은 비대하고 복잡한 코드를 양산했음
지금 존재하는 소프트웨어의 75%는 없어져도 세상이 더 나을 것 같음
예전에는 SSL이 존재하지 않았고, 처음 등장했을 때는 고가의 신기한 기술이었음
이후 암호화된 HTTP의 일반 명칭이 되었고, 프로토콜 이름이 TLS로 바뀌었어도 여전히 SSL로 불림
나는 여전히 SSL이라는 말을 자주 씀
암호 설정은 애플리케이션 개발자나 운영자에게 맡겨서는 안 됨 Go 블로그의 TLS Cipher Suites 글을 참고할 만함
Mozilla SSL Configuration Generator는 훌륭하지만, 사실 존재하지 않아야 할 도구임
암호 설정은 유지보수 비용이 크고, 시간이 지나면 점점 비효율적으로 변함
OpenSSL 같은 라이브러리에는 이미 cipher preset이 있었는데, 생성기가 그것을 확장하지 않은 게 이상함
예를 들어 “HIGH:!kRSA:!kEDH:!SHA1:!CAMELLIA:!ARIA”처럼 조합하면 안전성을 유지하면서도 최신 알고리즘을 사용할 수 있음
이런 설정은 ECC 키나 ChaCha20 같은 강력한 cipher suite를 실수로 비활성화하는 문제를 막아줌
EdDSA나 post-quantum hybrid 알고리즘을 지원하지 못하는 서버도 이런 이유로 생김
요즘 OCSP stapling을 포함시키는 게 아이러니함
브라우저와 Let's Encrypt가 이미 OCSP를 사실상 폐기했기 때문임
Hacker News 의견
비슷한 맥락으로, 웹사이트의 보안 헤더를 스캔할 수 있는 SecurityHeaders와 TLS 설정을 검증하는 SSL Labs Test, 그리고 커맨드라인에서 사이트를 스캔할 수 있는 testssl.sh 같은 도구가 있음
인터넷에 접근할 수 없는 환경이나 자동화된 HTML 리포트 생성 시 유용함
병렬화와 옵션 비활성화에도 최소 20초가 걸렸는데, 새 도구는 60~100배 빠름
취약점 분석은 없지만, 설정 추출이 목적이었음
각 헤더는 기능이 다르고, 사이트 목적에 따라 적용하지 않아야 할 경우도 있음
예를 들어 CSP 헤더가 있어도 실제로는 무의미하게 설정된 경우가 많음
왜 아직도 “SSL”이라는 용어를 쓰는지 모르겠음
지난 10년간의 기술 발전을 잊은 것처럼 느껴짐
고객에게 TLS 인증서를 설정한다고 하면 “우린 SSL이 필요하다”고 걱정하는 경우가 많음
결국 인지도 문제임. 일반 사용자는 TLS를 모르고, 기업은 혼란을 피하려고 SSL을 계속 씀
Cloudflare의 SSL 페이지도 경로는 SSL이지만 내용은 TLS 중심이라 혼란스러움
Netscape Navigator가 Mozilla로 이어졌기 때문에 Mozilla가 여전히 SSL 용어를 많이 쓰는 것도 이해됨
지금 존재하는 소프트웨어의 75%는 없어져도 세상이 더 나을 것 같음
이후 암호화된 HTTP의 일반 명칭이 되었고, 프로토콜 이름이 TLS로 바뀌었어도 여전히 SSL로 불림
암호 설정은 애플리케이션 개발자나 운영자에게 맡겨서는 안 됨
Go 블로그의 TLS Cipher Suites 글을 참고할 만함
Mozilla SSL Configuration Generator는 훌륭하지만, 사실 존재하지 않아야 할 도구임
OpenSSL 같은 라이브러리에는 이미 cipher preset이 있었는데, 생성기가 그것을 확장하지 않은 게 이상함
예를 들어 “HIGH:!kRSA:!kEDH:!SHA1:!CAMELLIA:!ARIA”처럼 조합하면 안전성을 유지하면서도 최신 알고리즘을 사용할 수 있음
이런 설정은 ECC 키나 ChaCha20 같은 강력한 cipher suite를 실수로 비활성화하는 문제를 막아줌
EdDSA나 post-quantum hybrid 알고리즘을 지원하지 못하는 서버도 이런 이유로 생김
요즘 OCSP stapling을 포함시키는 게 아이러니함
브라우저와 Let's Encrypt가 이미 OCSP를 사실상 폐기했기 때문임
Mozilla는 SSH 설정 가이드도 제공함
OpenSSH 보안 가이드라인 참고 가능함
서버 개발자가 연도나 보안 수준(secure, medium, loose)만 지정하면 되는 턴키 구성을 제공했으면 좋겠음
SSL cipher를 고르는 건 거의 카고 컬트 수준이라, 뭘 하는지 모르겠음
왜 SSLHonorCipherOrder를 Off로 설정하라고 권장하는지 궁금했음
Modern과 Intermediate 수준의 cipher는 모두 안전하므로, 클라이언트가 하드웨어에 맞는 cipher를 선택하게 두는 것이 효율적임
관련 내용은 이슈 코멘트와 Mozilla 위키에 정리되어 있음
설정 생성기에서 mTLS(상호 TLS) 옵션이 없는 게 아쉬움
클라이언트 인증서가 필요한 상황에서는 매우 유용한데, 너무 니치한 기능이라 빠진 듯함
“AWS ELB” 항목이 Classic Load Balancer를 의미하는 듯함
지금은 “AWS ALB”가 Application Load Balancer이므로 용어가 혼동됨
OpenSSL 설정을 위한 비슷한 도구가 있으면 좋겠음