# Mozilla의 SSL Configuration 생성기

> Clean Markdown view of GeekNews topic #24385. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24385](https://news.hada.io/topic?id=24385)
- GeekNews Markdown: [https://news.hada.io/topic/24385.md](https://news.hada.io/topic/24385.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-11-16T07:32:43+09:00
- Updated: 2025-11-16T07:32:43+09:00
- Original source: [ssl-config.mozilla.org](https://ssl-config.mozilla.org/)
- Points: 2
- Comments: 1

## Topic Body

- 다양한 **서버 소프트웨어**에 맞는 SSL/TLS 설정을 자동으로 생성하는 도구  
- Apache, nginx, HAProxy, Tomcat 등 20여 종의 서버 환경을 지원  
- **Modern**, **Intermediate**, **Old** 세 가지 **Mozilla 구성 프로파일**을 제공해 보안 수준과 호환성 선택 가능  
- OpenSSL 버전과 서버 버전을 입력해 맞춤형 설정 생성, HTTPS 리다이렉트 옵션 포함  
- Mozilla의 **보안 가이드라인**과 연계되어 안전한 서버 설정을 쉽게 구현할 수 있는 유용한 도구  
  
---  
### 개요  
- **Mozilla SSL Configuration Generator**는 서버 관리자가 안전한 SSL/TLS 구성을 손쉽게 생성할 수 있도록 지원하는 웹 기반 도구  
- Mozilla의 보안 정책과 TLS 권장 설정을 기반으로, 각 서버 환경에 맞는 설정 스크립트를 자동 생성  
  
### 지원 서버 소프트웨어  
- 지원 대상에는 **Apache**, **AWS ALB/ELB**, **Caddy**, **Coturn**, **Dovecot**, **Exim**, **Go**, **HAProxy**, **Jetty**, **lighttpd**, **MySQL**, **nginx**, **Oracle HTTP**, **Postfix**, **PostgreSQL**, **ProFTPD**, **Redis**, **Squid**, **stunnel**, **Tomcat**, **Traefik** 등이 포함  
- 각 서버별로 최적화된 SSL 설정 템플릿을 제공  
  
### Mozilla 구성 프로파일  
- **Modern**: TLS 1.3을 지원하며, 하위 호환성이 필요 없는 최신 서비스용  
- **Intermediate**: 다양한 클라이언트와의 호환성을 고려한 일반 서버용, 대부분의 시스템에 권장  
- **Old**: 매우 오래된 클라이언트와의 호환성을 유지해야 하는 경우에만 사용  
  
### 환경 설정 항목  
- **Server Version**과 **OpenSSL Version**을 입력하여 해당 환경에 맞는 설정 생성  
- HTTPS 리다이렉트 기능을 포함하며, **JavaScript 활성화**가 필요  
  
### 참고 및 리소스  
- Mozilla의 공식 문서와 보안 가이드라인으로 연결되는 링크 제공  
  - [Server Side TLS configurations](https://wiki.mozilla.org/Security/Server_Side_TLS)  
  - [Web Security guidelines](https://infosec.mozilla.org/guidelines/web_security)  
  - [Transport Layer Security on MDN](https://developer.mozilla.org/docs/Web/Security/Transport_Layer_Security)  
  - [Mozilla HTTP Observatory](https://observatory.mozilla.org/)  
  - [Qualys SSL Labs Server Test](https://www.ssllabs.com/ssltest/)

## Comments



### Comment 46362

- Author: neo
- Created: 2025-11-16T07:32:44+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45932798) 
- 비슷한 맥락으로, 웹사이트의 **보안 헤더를 스캔**할 수 있는 [SecurityHeaders](https://securityheaders.com/)와 TLS 설정을 검증하는 [SSL Labs Test](https://www.ssllabs.com/ssltest/), 그리고 커맨드라인에서 사이트를 스캔할 수 있는 [testssl.sh](https://github.com/testssl/testssl.sh) 같은 도구가 있음  
  인터넷에 접근할 수 없는 환경이나 자동화된 HTML 리포트 생성 시 유용함
  - 내부 네트워크에서 스캔이 필요했는데, testssl.sh가 너무 느려서 직접 만든 스캐너 [hello_tls](https://github.com/boppreh/hello_tls)를 사용함  
    병렬화와 옵션 비활성화에도 최소 20초가 걸렸는데, 새 도구는 **60~100배 빠름**  
    취약점 분석은 없지만, 설정 추출이 목적이었음
  - 하지만 security headers 사이트에는 동의하지 않음  
    각 헤더는 기능이 다르고, 사이트 목적에 따라 **적용하지 않아야 할 경우**도 있음  
    예를 들어 CSP 헤더가 있어도 실제로는 무의미하게 설정된 경우가 많음

- 왜 아직도 “**SSL**”이라는 용어를 쓰는지 모르겠음  
  지난 10년간의 기술 발전을 잊은 것처럼 느껴짐
  - 나도 “TLS”를 쓰지만 쉽지 않음  
    고객에게 TLS 인증서를 설정한다고 하면 “우린 SSL이 필요하다”고 걱정하는 경우가 많음  
    결국 **인지도 문제**임. 일반 사용자는 TLS를 모르고, 기업은 혼란을 피하려고 SSL을 계속 씀  
    Cloudflare의 [SSL 페이지](https://www.cloudflare.com/application-services/products/ssl/)도 경로는 SSL이지만 내용은 TLS 중심이라 혼란스러움
  - SSL은 90년대 Netscape가 개발했고, 이후 TLS로 발전했음  
    Netscape Navigator가 Mozilla로 이어졌기 때문에 Mozilla가 여전히 SSL 용어를 많이 쓰는 것도 이해됨
  - 지난 10년간의 기술은 **비대하고 복잡한 코드**를 양산했음  
    지금 존재하는 소프트웨어의 75%는 없어져도 세상이 더 나을 것 같음
  - 예전에는 SSL이 존재하지 않았고, 처음 등장했을 때는 **고가의 신기한 기술**이었음  
    이후 암호화된 HTTP의 일반 명칭이 되었고, 프로토콜 이름이 TLS로 바뀌었어도 여전히 SSL로 불림
  - 나는 여전히 SSL이라는 말을 자주 씀

- 암호 설정은 애플리케이션 개발자나 운영자에게 맡겨서는 안 됨  
  [Go 블로그의 TLS Cipher Suites 글](https://go.dev/blog/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 보안 가이드라인](https://infosec.mozilla.org/guidelines/openssh) 참고 가능함

- 서버 개발자가 연도나 보안 수준(secure, medium, loose)만 지정하면 되는 **턴키 구성**을 제공했으면 좋겠음  
  SSL cipher를 고르는 건 거의 **카고 컬트** 수준이라, 뭘 하는지 모르겠음

- 왜 SSLHonorCipherOrder를 Off로 설정하라고 권장하는지 궁금했음
  - nginx에서도 같은 이유로 Off를 권장함  
    Modern과 Intermediate 수준의 cipher는 모두 안전하므로, **클라이언트가 하드웨어에 맞는 cipher**를 선택하게 두는 것이 효율적임  
    관련 내용은 [이슈 코멘트](https://github.com/mozilla/server-side-tls/issues/260#issuecomment-507392266)와 [Mozilla 위키](https://wiki.mozilla.org/Security/Server_Side_TLS)에 정리되어 있음

- 설정 생성기에서 **mTLS(상호 TLS)** 옵션이 없는 게 아쉬움  
  클라이언트 인증서가 필요한 상황에서는 매우 유용한데, 너무 **니치한 기능**이라 빠진 듯함
  - 웹서버 초기 통신 설정에 초점을 둔 도구라, 인증 메커니즘은 범위 밖임
  - 클라이언트 인증서를 다루려면 **CA 구축 등 고급 지식**이 필요하므로 확실히 한정된 영역임

- “AWS ELB” 항목이 **Classic Load Balancer**를 의미하는 듯함  
  지금은 “AWS ALB”가 Application Load Balancer이므로 용어가 혼동됨
  - 아마 ALB가 등장하기 전부터 존재하던 설정이라, 업데이트가 많지 않은 듯함

- OpenSSL 설정을 위한 비슷한 도구가 있으면 좋겠음