SSL/TLS 암호화 모드 4가지 (Off / Flexible / Full / Full Strict)

SSL/TLS 암호화 모드 4가지 완전 정리

Cloudflare에서 SSL/TLS 메뉴를 열면 Off / Flexible / Full / Full (Strict) 네 개가 나옵니다. 이름만 보면 Flexible이 유연해서 좋아 보이고 Strict는 까다로워 보입니다. 그런데 실제로는 정반대입니다. 이 선택 하나가 보안 수준과 리디렉션 루프 발생 여부를 동시에 결정합니다.

안녕하세요, 코딩하는 안다형입니다. 이 글에서는 네 가지 암호화 모드가 정확히 어디까지 암호화하는지를 구간으로 나눠 정리했습니다. 그림 하나만 머리에 넣으면 헷갈릴 일이 없습니다.

3줄 요약
1. 통신 구간은 방문자에서 Cloudflare까지와 Cloudflare에서 원본 서버까지 두 개입니다.
2. Flexible은 앞 구간만 암호화합니다. 뒤 구간은 평문으로 오갑니다.
3. 목표는 Full (Strict)입니다. 원본에 인증서를 설치하면 무료로 쓸 수 있습니다.

모드 고르는 순서: 원본 확인, 없는 경우, 있는 경우, 검증

먼저 구간을 나눠서 봐야 합니다

프록시를 켜면 통신이 두 토막으로 나뉩니다. 이걸 구분하지 않으면 어떤 모드가 안전한지 판단할 수 없습니다.

• 1구간, 방문자 → Cloudflare: 브라우저 주소창의 자물쇠가 보여주는 구간입니다. 방문자가 눈으로 확인할 수 있습니다.
• 2구간, Cloudflare → 원본 서버: 방문자에게는 보이지 않습니다. 여기가 평문이어도 브라우저에는 자물쇠가 정상으로 표시됩니다.

문제는 여기입니다. 2구간이 평문이어도 방문자는 알 수 없습니다. 자물쇠가 잠겨 있으니 안전하다고 믿게 됩니다. 그래서 "https로 보이는데 왜 문제냐"는 오해가 생깁니다.

네 가지 모드를 하나씩

Off (암호화 없음)

https 요청을 http로 되돌립니다. 두 구간 모두 평문입니다. 쓸 이유가 없습니다. 검색 노출에도 불리하고 브라우저가 경고를 띄웁니다. 이 항목은 존재만 알아 두면 됩니다.

Flexible (앞 구간만 암호화)

1구간은 https, 2구간은 http입니다. 원본 서버에 인증서가 없어도 사이트를 https로 보이게 만들 수 있어서 처음에 많이 선택합니다. 자물쇠가 잠기니 다 된 것처럼 보이죠.

그런데 두 가지 문제가 있습니다.

• 보안이 반쪽입니다. Cloudflare와 원본 서버 사이 데이터가 평문으로 흐릅니다. 로그인 정보나 개인정보가 이 구간을 지나갑니다.
• 리디렉션 루프의 주범입니다. Cloudflare가 원본에 http로 요청하면, 원본은 "https로 오세요"라고 되돌려 보냅니다. 그러면 Cloudflare가 다시 http로 요청하고, 이게 무한 반복됩니다. ERR_TOO_MANY_REDIRECTS의 가장 흔한 원인입니다.

Flexible은 인증서를 설치하기 전까지의 임시 상태로만 쓰세요. 그리고 이 상태에서는 원본 서버의 https 강제 리다이렉트를 반드시 꺼야 합니다.

Full (양쪽 암호화, 검증은 안 함)

두 구간 모두 https입니다. 다만 Cloudflare가 원본 서버의 인증서를 검증하지 않습니다. 만료된 인증서든 자체 서명한 인증서든 그냥 받아들입니다.

Flexible보다 확실히 낫습니다. 평문 구간이 없어지고 루프 문제도 사라집니다. 다만 인증서를 확인하지 않으니 중간에서 가로채는 공격에는 취약합니다. 자체 서명 인증서만 있는 상황의 차선책입니다.

Full (Strict) (양쪽 암호화 + 인증서 검증)

두 구간 모두 https이고, Cloudflare가 원본 인증서가 유효한지까지 확인합니다. 만료됐거나 도메인이 안 맞으면 연결을 거부합니다. 이게 목표 상태입니다.

"인증서를 사야 하나?"라는 걱정은 안 해도 됩니다. Cloudflare가 Origin 인증서를 무료로 발급해 줍니다. 유효기간을 최대 15년까지 지정할 수 있어서 갱신 부담도 없습니다. Let's Encrypt로 발급받아 쓰는 방법도 있습니다.

그래서 무엇을 골라야 하나

판단은 원본 서버에 인증서가 있는지 하나로 갈립니다.

• 있고 정상이다: 바로 Full (Strict)로 두세요. 끝입니다.
• 있지만 자체 서명이거나 만료됐다: 우선 Full로 두고, 시간 나면 Origin 인증서를 새로 발급해 Strict로 올리세요.
• 없다: Origin 인증서를 발급받아 설치한 뒤 Full (Strict)로 갑니다. 30분이면 됩니다.
• 지금 당장 급하다: Flexible로 임시 조치하되, 원본의 https 강제 리다이렉트를 끄고 이번 주 안에 정리하세요.

Off와 Flexible, Full, Full Strict의 암호화 구간 비교표

암호화 모드 비교

• Off: 암호화가 전혀 없습니다. 사용 금지입니다.
• Flexible: 방문자와 Cloudflare 구간만 암호화됩니다. 임시로만 쓰세요.
• Full: 양쪽 구간을 암호화하지만 인증서를 검증하지 않습니다. 차선책입니다.
• Full (Strict): 양쪽 구간 암호화에 인증서 검증까지 합니다. 권장입니다.

모드를 바꾸기 전에 확인할 것

원본 서버의 443번 포트가 열려 있는가

Full이나 Strict로 바꾸면 Cloudflare가 원본에 https(443번)로 접속합니다. 그동안 80번만 열어 뒀다면 연결이 실패하고 525나 526 오류가 뜹니다. 모드를 바꾸기 전에 웹서버가 443번을 듣고 있는지 확인하세요.

sudo ss -lntp | grep ':443'
curl -k -I https://원본IP주소/

인증서의 도메인이 맞는가

Strict는 인증서에 적힌 도메인이 실제 요청 도메인과 일치하는지 봅니다. 다른 도메인용 인증서가 설치돼 있으면 거부됩니다. Origin 인증서를 발급할 때 내도메인.com과 *.내도메인.com을 함께 넣어 두면 이런 문제가 없습니다.

서브도메인마다 다른 모드가 필요한가

암호화 모드는 도메인 전체에 적용되는 설정입니다. 서브도메인 하나만 다르게 두고 싶다면 별도 규칙을 만들어야 합니다. 대부분의 개인 사이트는 전체를 Full (Strict)로 통일하는 게 관리가 편합니다.

오류 코드로 원인 찾기

모드를 바꾼 직후 오류가 나면 코드가 원인을 알려 줍니다.

• 525 SSL handshake failed: 원본과 SSL 연결 자체가 안 됐습니다. 443번 포트나 웹서버 SSL 설정을 확인하세요.
• 526 Invalid SSL certificate: 연결은 됐지만 인증서 검증에 실패했습니다. 만료됐거나 도메인이 안 맞거나 자체 서명입니다. Strict에서만 나타납니다.
• ERR_TOO_MANY_REDIRECTS: Flexible과 서버의 https 강제가 충돌한 것입니다. 모드를 Full로 올리면 대개 해결됩니다.
• 혼합 콘텐츠 경고: 모드와 별개 문제입니다. 본문에 http 주소가 남아 있는 것입니다.

이건 하지 마세요

• Flexible을 최종 상태로 두기: 절반만 암호화된 채로 운영됩니다. 로그인이 있는 사이트라면 특히 위험합니다.
• 인증서 설치 전에 Strict로 바꾸기: 사이트가 즉시 멈춥니다. 순서는 인증서 먼저, 모드 나중입니다.
• 루프가 난다고 서버의 https 강제만 끄고 방치: 증상은 사라지지만 http 접속이 그대로 남습니다. 모드를 Full로 올리는 게 정답입니다.
• 브라우저 자물쇠만 보고 안심하기: 자물쇠는 1구간만 보여 줍니다. 2구간은 Cloudflare 설정에서 확인해야 합니다.
• 모드를 자주 오가며 테스트하기: 캐시와 브라우저 상태가 섞여 판단이 흐려집니다. 한 번 바꾸고 시크릿 창으로 확인하세요.

자주 묻는 질문

Q. Flexible인데 자물쇠가 잠겨 있습니다. 안전한 거 아닌가요?

아닙니다. 자물쇠는 방문자와 Cloudflare 사이만 보여 줍니다. Cloudflare와 원본 서버 사이는 평문입니다. 방문자는 이 사실을 알 수 없기 때문에 오히려 더 문제입니다.

Q. 인증서를 돈 내고 사야 하나요?

아닙니다. Cloudflare의 Origin 인증서를 무료로 발급받아 원본 서버에 설치하면 됩니다. 유효기간을 최대 15년으로 지정할 수 있어 갱신 신경도 안 씁니다. Let's Encrypt를 써도 무료입니다.

Q. Full과 Full (Strict) 차이가 실제로 큰가요?

암호화 자체는 둘 다 됩니다. 차이는 상대가 진짜 내 서버인지 확인하는지입니다. Full은 확인하지 않으므로 중간자 공격에 취약합니다. 설치 난이도가 같으니 Strict를 쓰는 게 맞습니다.

Q. Strict로 바꾸니 526 오류가 납니다.

원본 인증서가 검증을 통과하지 못한 것입니다. 만료 여부, 도메인 일치 여부, 자체 서명 여부를 확인하세요. Origin 인증서를 새로 발급해 설치하면 대부분 해결됩니다.

Q. 공유 호스팅인데 인증서를 설치할 수 있나요?

업체가 인증서 설치 기능을 제공하면 가능합니다. 요즘은 대부분 무료 인증서를 자동 발급해 주므로, 그 상태라면 바로 Full (Strict)로 둘 수 있습니다. 설치가 불가능한 환경이면 Full로 두고 운영하세요.

Q. 모드를 바꾸면 SEO에 영향이 있나요?

암호화 모드 자체는 검색 노출에 직접 영향이 없습니다. 다만 루프나 인증서 오류로 페이지가 안 열리면 크롤링이 실패해 큰 손해가 됩니다. 그래서 오류가 안 나는 상태로 안정화하는 게 중요합니다.

마무리

정리하면 구간은 두 개, 목표는 Full (Strict)입니다. Flexible은 원본에 인증서가 없을 때의 임시 조치일 뿐, 최종 답이 아닙니다.

순서만 기억하세요. 원본에 인증서 설치 → 443번 포트 확인 → Full (Strict)로 전환입니다. 이 순서를 지키면 사이트가 멈추는 일 없이 안전한 상태로 올라갈 수 있습니다.

 

함께 보면 좋은 글

• 웹호스팅 · VPS · 클라우드 뭘 골라야 할까
• 티스토리 2차 도메인 연결하는 방법
• 그누보드 메일 발송 설정하는 방법