대상 OS: Ubuntu Server 24.04 LTS

서버 보안은 “취약점 패치”만으로 끝나지 않습니다.
이미 안전하지 않은 TLS 설정(낡은 프로토콜/약한 암호군)을 그대로 두면, 공격자는 그 약한 지점을 골라 들어옵니다.
Ubuntu 24.04는 OpenSSL 3.0 기반이라 기본 보안 수준이 올라갔지만, 여전히 레거시 설정/커스텀 설정이 남아 있으면 약한 TLS가 살아 있을 수 있습니다.
특히 NGINX 같은 웹 프록시와 OpenSSH(SSH 자체는 TLS가 아니지만, 암호/키 교환 정책 점검이 필요)는 운영에서 가장 자주 맞닥뜨리는 영역입니다.

이 글은 Ubuntu 24.04(OpenSSL 3.0) 환경에서 “TLS 최소 버전/암호군을 명확히” 하고, 실제 서비스(NGINX)와 점검(sslscan 대체로 openssl s_client)을 통해 확인하며, 호환성 이슈를 안전하게 풀어가는 방법을 정리합니다.

---

1) 목표: 무엇을 ‘정리’할 것인가

1) TLS 1.0/1.1 비활성화(현대 환경에서는 사실상 퇴출)

2) TLS 1.2/1.3만 허용(서비스 성격에 따라 1.2만도 가능)

3) 취약/구형 암호군 차단(3DES, RC4 등)

4) 설정 변경 후 실제 핸드셰이크로 검증

5) 호환성 요구가 있으면 “예외를 최소 범위로”

---

2) 현재 OpenSSL 3.0/시스템 상태 확인

1) OpenSSL 버전 확인

openssl version -a

2) 기본 보안 프로파일(암호 정책) 확인

ls -la /etc/ssl
ls -la /etc/ssl/openssl.cnf

3) OpenSSL이 어떤 프로토콜을 지원하는지 확인

openssl ciphers -v | head -n 30

---

3) (중요) OpenSSL 전역 설정은 ‘신중하게’

OpenSSL 전역 설정(`/etc/ssl/openssl.cnf`)을 건드리면, 서버 전체의 TLS 동작이 바뀔 수 있습니다.
그래서 실무에서는 보통 다음 순서가 안전합니다.

1) 먼저 “서비스 단(예: NGINX)”에서 TLS 정책을 명확히 한다

2) 그 다음에 조직 표준이 필요하면 전역 정책을 검토한다

이 글도 “서비스 단 설정” 중심으로 진행합니다.

---

4) NGINX에서 TLS 최소 버전/암호군 정리

NGINX가 설치되어 있다고 가정합니다(없다면 설치 후 적용).

1) 설정 파일 위치 확인

nginx -V 2>&1 | head -n 5 || true
sudo nginx -t || true
sudo ls -la /etc/nginx | sed -n '1,120p'

2) TLS 1.2/1.3만 허용하는 기본 예시

아래는 서버 블록 안(https listen)에서 쓰는 예시입니다.

sudo tee /etc/nginx/snippets/tls-modern.conf >/dev/null /dev/null || true

(편집은 환경마다 다르므로, 실제 적용은 수동 편집을 권장합니다.)

4) 문법 검증 및 reload

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

운영 팁
- `ssl_prefer_server_ciphers`는 TLS 1.2에서 의미가 있고, TLS 1.3에는 적용 방식이 다릅니다.
- 가능한 한 TLS 1.3을 켜고, TLS 1.2는 호환성을 위해 유지하는 형태가 보편적입니다.

---

5) 실제 핸드셰이크로 검증(openssl s_client)

설정은 설정일 뿐이고, 실제로 클라이언트가 접속해봐야 확실합니다.

1) TLS 1.0으로 접속 시도(실패해야 정상)

openssl s_client -connect your.domain:443 -tls1 2>/dev/null | head -n 20

2) TLS 1.1으로 접속 시도(실패해야 정상)

openssl s_client -connect your.domain:443 -tls1_1 2>/dev/null | head -n 20

3) TLS 1.2로 접속(성공해야 정상)

openssl s_client -connect your.domain:443 -tls1_2 2>/dev/null | grep -E 'Protocol|Cipher' | head -n 20

4) TLS 1.3로 접속(성공해야 정상)

openssl s_client -connect your.domain:443 -tls1_3 2>/dev/null | grep -E 'Protocol|Cipher' | head -n 20

검증 포인트
- Protocol이 TLSv1.2 또는 TLSv1.3인지
- Cipher가 의도한 강한 스위트인지

---

6) 호환성 트러블슈팅: “구형 클라이언트가 안 붙는다”

여기서 가장 흔한 케이스는 다음입니다.

1) 레거시 OS/브라우저가 TLS 1.2를 제대로 못 한다

2) 오래된 Java/임베디드 클라이언트가 특정 cipher만 지원한다

3) 중간 프록시/보안 장비가 TLS 1.3을 문제 삼는다

대응 원칙은 “예외를 최소화”입니다.

1) 예외가 필요한 대상/시간을 명확히

2) 가능하면 별도 엔드포인트(서브도메인/별도 리스너)로 분리

3) 예외는 문서화하고 만료(언제까지)

예: 특정 레거시 클라이언트 때문에 TLS 1.2 cipher를 한두 개 추가해야 하는 경우, 전체 설정을 느슨하게 풀기보다 필요한 최소만 추가합니다.

---

7) OpenSSH도 같이 점검해야 하는 이유(암호 정책 관점)

SSH는 TLS가 아니지만, “암호/키 교환 정책을 최신으로 유지”하는 건 같은 결의 작업입니다.
Ubuntu 24.04의 OpenSSH는 기본적으로 안전한 편이지만, 오래된 설정이 남아 있으면 약한 알고리즘을 허용할 수 있습니다.

1) 현재 SSH 알고리즘(유효 설정) 확인

sudo sshd -T | grep -E 'kexalgorithms|ciphers|macs|hostkeyalgorithms' | head -n 50

2) 클라이언트에서 실제 협상 확인(관찰)

ssh -vvv [email protected] 2>&1 | grep -E 'kex: algorithm|kex: host key algorithm|kex: cipher|kex: mac' | head -n 40

운영 포인트
- TLS를 정리했는데 SSH는 방치하면 “관리 채널”이 약해질 수 있습니다.
- SSH는 가능하면 키 인증/SSH CA/관리망 접근과 함께 운영하세요.

---

8) 롤아웃 전략: 한 번에 바꾸지 말기

TLS 정책은 고객/파트너/내부 시스템 호환성과 맞물립니다.
그래서 안전한 롤아웃은 보통 이 흐름입니다.

1) 현재 핸드셰이크/클라이언트 통계를 수집한다

2) staging에서 먼저 TLS 1.0/1.1을 끈다

3) prod는 점진 적용(서브도메인, 특정 리스너, 또는 점검 기간)

4) 문제 클라이언트는 예외 엔드포인트로 격리하고, 만료 시점을 정한다

---

마무리

Ubuntu 24.04(OpenSSL 3.0) 환경은 기본 보안 수준이 높지만, “내 서비스가 실제로 어떤 TLS를 내보내는지”는 설정에 달려 있습니다.
TLS 1.0/1.1을 정리하고, TLS 1.2/1.3만 허용하며, 강한 암호군으로 정리하는 것만으로도 공격면이 확 줄어듭니다.

핵심은
- 서비스 단에서 명확히 설정
- openssl s_client로 실제 검증
- 호환성 예외는 최소 범위로
입니다.