보안 헤더 & 암호화로 철통 방어하기

Kylie·2025년 7월 21일

WEB

목록 보기
5/7

들어가기 전

인터넷으로 데이터를 주고받을 때, 마치 엽서를 우편함에 넣어 보내는 것과 같아요. 누구든 중간에 엽서 내용을 볼 수 있죠. 이처럼 중요한 데이터가 안전하게 전달되도록 돕는 것이 바로 보안 헤더와 암호화입니다.

보안 헤더는 웹 브라우저와 서버가 서로 지켜야 할 약속(규칙)을 정하는 역할을 해요. 예를 들어, '이 웹사이트는 무조건 HTTPS로만 접속해야 해!' 같은 규칙을 알려주는 거죠.

암호화는 데이터 내용을 알아볼 수 없도록 꽁꽁 싸매는 거예요. 마치 비밀 편지를 암호로 쓰는 것처럼요. 이렇게 하면 제3자가 중간에 데이터를 가로채도 내용을 읽을 수 없게 됩니다.

1. HTTPS와 TLS: 안전한 웹의 시작

1-1. SSL vs TLS: 이름은 다르지만 결국 '그 기술'이 발전한 거예요!

웹을 안전하게 지켜주는 암호화 기술에는 SSL(Secure Sockets Layer) 과 TLS(Transport Layer Security) 가 있어요. 쉽게 말해, SSL이 먼저 나왔고, TLS는 SSL의 업그레이드 버전이라고 생각하면 돼요.

우리가 흔히 'SSL 인증서'라고 부르지만, 실제로 웹 통신을 암호화하는 건 이 인증서를 서버에 설치해서 TLS 프로토콜을 사용하게 하는 거예요.

  • SSL: 1990년대 초에 처음 나왔지만, 보안에 약점(POODLE 같은 공격)이 발견돼서 지금은 거의 쓰지 않아요. 오래된 기술이죠.
  • TLS: SSL을 더욱 강력하고 빠르게 만든 후속 버전이에요. 지금은 대부분의 웹사이트가 TLS 1.2를 쓰고 있고, 가장 최신 버전인 TLS 1.3은 훨씬 더 빠르고 안전해서 적극 권장되고 있어요.
프로토콜 이름주요 특징지금 사용해도 될까요?
SSL 3.0초창기 암호화 기술사용하지 마세요! 보안에 취약해요.
TLS 1.0SSL 3.0을 개선했지만 여전히 오래된 기술아주 오래된 환경이 아니라면 사용하지 마세요.
TLS 1.2강력한 암호화, 빠르고 안전함지금 대부분의 웹사이트에서 쓰고 있어요!
TLS 1.3더 빠르고, 더 안전한 최신 기술가장 추천하는 버전이에요!

💡 웹사이트 서버에서는 최소한 TLS 1.2 이상을 사용해야 하고, 가능하면 TLS 1.3만 허용해서 최고 수준의 보안과 속도를 확보하는 것이 좋아요.

1-2. HTTPS 적용 과정: 내 웹사이트에 자물쇠 달아주기

HTTPS는 웹사이트 주소 앞에 🔓'자물쇠' 모양이 생기고 'https://'로 시작하게 하는 거예요. 이걸 적용하려면 다음 과정을 거쳐야 해요.

  1. 인증서 발급받기:

    • Let's Encrypt (무료), DigiCert, GlobalSign (유료) 같은 전문 기관에서 '우리 웹사이트가 진짜예요!'라는 것을 증명하는 인증서를 발급받아요.
    • 예시: Let's Encrypt의 Certbot 사용 (리눅스 명령어)
      sudo certbot certonly --standalone -d example.com -d www.example.com
      이 명령어를 입력하면 example.com과 www.example.com 도메인에 대한 인증서를 자동으로 발급받을 수 있어요. 발급된 인증서는 fullchain.pem(인증서 파일)과 privkey.pem(개인키 파일)이라는 이름으로 저장됩니다.

  2. 서버에 인증서 설치하기:

    • 발급받은 인증서 파일을 웹사이트가 돌아가는 서버에 설정해 줘야 해요. 서버 종류마다 설정 방법이 조금씩 달라요.

    • NGINX (엔진엑스) 서버 예시:

      server {
  listen 443 ssl; # 443 포트로 HTTPS 접속을 받아요
  server_name example.com; # 이 도메인에 적용해요

  ssl_certificate       /etc/letsencrypt/live/example.com/fullchain.pem; # 인증서 파일 위치
  ssl_certificate_key   /etc/letsencrypt/live/example.com/privkey.pem; # 개인키 파일 위치

  ssl_protocols         TLSv1.2 TLSv1.3; # TLS 1.2와 1.3만 허용해요
  ssl_ciphers           HIGH:!aNULL:!MD5; # 안전한 암호화 방식만 사용해요

  # 기타 필요한 설정들...
}

    • Apache (아파치) 서버 예시:

      <VirtualHost *:443> # 443 포트로 HTTPS 접속을 받아요
  ServerName example.com # 이 도메인에 적용해요

  SSLEngine on # SSL/TLS 기능을 켜요
  SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem # 인증서 파일 위치
  SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem # 개인키 파일 위치

  SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 # SSLv3, TLSv1, TLSv1.1은 사용하지 않아요
  SSLCipherSuite HIGH:!aNULL:!MD5 # 안전한 암호화 방식만 사용해요

  # 기타 필요한 설정들...
</VirtualHost>

    • Express.js (Node.js) 웹 애플리케이션 예시:

      const fs = require('fs');
const https = require('https'); // HTTPS 모듈을 불러와요
const express = require('express');

const app = express();
const options = {
  key: fs.readFileSync('/etc/letsencrypt/live/example.com/privkey.pem'), // 개인키 파일 읽기
  cert: fs.readFileSync('/etc/letsencrypt/live/example.com/fullchain.pem'), // 인증서 파일 읽기
};

https.createServer(options, app).listen(443, () => { // HTTPS 서버를 443 포트로 시작
  console.log('HTTPS server running on port 443');
});

  3. 인증서 자동 갱신 설정하기:

    • Let's Encrypt 인증서는 90일마다 갱신해야 해요. 매번 수동으로 하면 너무 번거롭겠죠? certbot renew 명령을 컴퓨터가 알아서 실행하도록 설정(크론탭 등록)해두면 편리해요.
    • 자동 갱신 명령어 (리눅스)
      0 0 * * * certbot renew --quiet
      이 명령은 매일 자정(새벽 0시)에 certbot renew를 조용히 실행하라는 뜻이에요.

  4. 제대로 적용되었는지 확인하기:

    • openssl이라는 명령어를 사용해서 여러분의 웹사이트가 어떤 TLS 버전을 쓰고 있는지, 암호화 강도는 어떤지 확인할 수 있어요.
      openssl s_client -connect example.com:443 -tls1_2
    • 또는 SSL Labs의 SSL Server Test 같은 온라인 도구를 사용하면 훨씬 쉽게 웹사이트의 HTTPS 설정을 점검해 볼 수 있어요.

Tip: 사람들이 http://example.com으로 접속해도 자동으로 https://example.com으로 연결되도록 서버 설정을 해주는 걸 잊지 마세요! (NGINX에서는 return 301 https://$host$request_uri; 같은 설정을 사용해요.)

2. HTTP/2 & HTTP/3: 웹사이트를 더 빠르고 안전하게!

HTTP는 웹에서 데이터를 주고받는 규칙인데, 버전이 계속 업그레이드되고 있어요. 최신 버전들은 보안과 속도를 모두 잡았답니다.

2-1. HTTP/2의 보안 및 성능 이점

HTTP/2는 기존 HTTP/1.1보다 웹페이지를 훨씬 빠르게 로딩할 수 있게 해줘요.

  • 멀티플렉싱: 한 번에 여러 개의 요청(데이터)을 주고받을 수 있어요. 마치 하나의 도로에서 여러 대의 차가 동시에 달리는 것처럼요. 덕분에 암호화 과정(TLS 핸드쉐이크)에서 생기는 시간 지연을 줄일 수 있어요.
  • 헤더 압축(HPACK): 웹 통신 시 필요한 부가 정보(헤더)를 꽉 압축해서 보내요. 덕분에 네트워크 데이터를 절약할 수 있죠.
  • 서버 푸시: 웹페이지를 보여줄 때 필요한 이미지나 스타일(CSS), 스크립트(JS) 같은 파일들을 클라이언트(사용자 웹브라우저)가 요청하기도 전에 서버가 미리 보내줘요. 페이지가 훨씬 빨리 뜨겠죠?

2-2. HTTP/3 & QUIC: 차세대 웹의 주인공

HTTP/3는 아직 초기 단계이지만, 앞으로 웹의 표준이 될 강력한 프로토콜이에요.

  • **QUIC(퀵)**이라는 새로운 통신 규칙(UDP 기반)을 사용해요. 기존보다 연결 지연 시간을 확 줄여주고, 한 번 접속했던 웹사이트에 다시 방문할 때는 훨씬 더 빨리 데이터를 주고받을 수 있도록 해줘요 (이걸 0-RTT 연결이라고 불러요).
  • HTTP/2의 장점들(멀티플렉싱, 헤더 압축)을 그대로 가지고 있으면서, 네트워크 상태가 안 좋을 때(패킷 손실)도 데이터를 더 빨리 복구할 수 있는 능력이 있어요.

2-3. 내 웹사이트에 HTTP/2와 HTTP/3 적용하기

여러분의 웹사이트에 HTTP/2와 HTTP/3를 적용하려면, 사용 중인 서버가 이 기술들을 지원해야 해요.

1) NGINX (엔진엑스)에서 HTTP/2 활성화하기

server {
  listen 443 ssl http2; # 443 포트로 HTTPS와 HTTP/2를 함께 사용해요
  server_name example.com;

  ssl_certificate       /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key   /etc/letsencrypt/live/example.com/privkey.pem;

  ssl_protocols         TLSv1.2 TLSv1.3;
  add_header            Alt-Svc 'h2=":443"'; # 클라이언트에게 HTTP/2를 지원한다고 알려줘요
}

listen ... http2; 부분이 HTTP/2를 켜는 설정이에요.

2) NGINX (엔진엑스)에서 HTTP/3 (QUIC) 활성화하기

server {
  listen 443 ssl http2;
  listen 443 quic reuseport; # QUIC 프로토콜을 사용하고, 443 포트를 재사용해요
  server_name example.com;

  ssl_certificate       /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key   /etc/letsencrypt/live/example.com/privkey.pem;

  ssl_protocols         TLSv1.3; # QUIC는 TLS 1.3만 사용해요
  ssl_prefer_server_ciphers off;
  ssl_ciphers           TLS_AES_128_GCM_SHA256; # 사용할 암호화 방식

  add_header Alt-Svc 'h3-23=":443"'; # 클라이언트에게 HTTP/3를 지원한다고 알려줘요
  add_header QUIC-Status $quic;
}

HTTP/3(QUIC)를 사용하려면 NGINX와 OpenSSL 버전에 특별한 설정이 필요할 수 있어요.

3) Apache (아파치)에서 HTTP/2 활성화하기

LoadModule http2_module modules/mod_http2.so # HTTP/2 모듈을 불러와요
Protocols h2 http/1.1 # HTTP/2를 기본으로 사용하고, 없으면 HTTP/1.1을 사용해요

<VirtualHost *:443>
  ServerName example.com

  SSLEngine on
  SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

  ProtocolsHonorOrder On
  Protocols h2 h2c http/1.1
</VirtualHost>

mod_http2 모듈을 로드하고 Protocols 지시자로 우선순위를 정해줘요.

4) HTTP/3 지원 고려사항

Apache에서 HTTP/3는 아직 개발 중이어서 완벽하게 지원되진 않아요. 만약 HTTP/3를 웹사이트에 적용하고 싶다면, Cloudflare, Fastly, Google Cloud CDN 같은 CDN 서비스를 이용하는 것이 훨씬 쉽고 안정적인 방법이에요. 이런 서비스들이 대신 HTTP/3를 적용해 줄 거예요.

3. 웹사이트를 더 안전하게 만드는 '보안 헤더'들

웹사이트의 보안을 강화하기 위해 웹 브라우저에게 특별한 지시를 내리는 것이 바로 보안 관련 HTTP 헤더예요. 이것들을 설정하면 여러 가지 웹 공격을 막을 수 있어요.

3-1. Strict-Transport-Security (HSTS)

  • 역할: 이 웹사이트는 무조건 HTTPS로만 접속해야 한다고 강제하는 헤더예요. 한번 접속한 사용자의 브라우저는 앞으로 이 사이트에 접속할 때 항상 HTTPS로만 연결하려고 시도해요. 중간에서 공격자가 HTTP로 유도하는 것을 막아줘요.
  • 설정 예시:
    Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
    • max-age=31536000: 1년(3153만 6천 초) 동안 이 규칙을 기억하라는 뜻이에요.
    • includeSubDomains: 이 도메인의 모든 하위 도메인(예: https://www.google.com/search?q=blog.example.com)에도 적용하라는 뜻이에요.
    • preload: 이 사이트가 HSTS를 사용한다는 정보를 미리 웹 브라우저에 등록하도록 요청하는 거예요.

3-2. X-Frame-Options

  • 역할: 웹사이트가 다른 사이트에 '액자(프레임)' 형태로 삽입되는 것을 막아요. 이걸 안 막으면 클릭재킹(Clickjacking) 같은 공격에 취약해질 수 있어요. (클릭재킹은 사용자가 의도치 않게 악성 버튼을 누르게 만드는 공격이에요.)
  • 설정 예시:
    X-Frame-Options: DENY # 아예 다른 사이트에 삽입될 수 없게 해요
# 또는
X-Frame-Options: SAMEORIGIN # 같은 도메인 내에서만 삽입을 허용해요

3-3. X-Content-Type-Options

  • 역할: 웹 브라우저가 파일 형식을 멋대로 판단하는 것을 막아요. 이걸 MIME 스니핑 방지라고 하는데, 만약 웹사이트에 이미지 파일을 올렸는데 브라우저가 이걸 스크립트 파일로 오해해서 실행해버리면 보안 문제가 생길 수 있겠죠? 그걸 막아줘요.
  • 설정 예시:
    X-Content-Type-Options: nosniff
    • nosniff: '절대 멋대로 판단하지 말고, 서버가 보낸 Content-Type 헤더를 그대로 믿어라!'는 뜻이에요.

3-4. Referrer-Policy

  • 역할: 사용자가 어떤 링크를 클릭해서 다른 사이트로 이동할 때, 이전에 어떤 페이지에서 왔는지(참조 정보, Referrer)를 알려줄지 말지를 제어해요. 개인 정보 노출을 줄이는 데 도움이 돼요.
  • 설정 예시:
    Referrer-Policy: strict-origin-when-cross-origin
    • strict-origin-when-cross-origin: 다른 출처(도메인)로 이동할 때는 전체 URL 대신 https://example.com처럼 도메인만 보내주고, 같은 출처로 이동할 때는 전체 URL을 보내줘요.

3-5. Permissions-Policy (구 Feature-Policy)

  • 역할: 웹페이지에서 카메라, 마이크, GPS 같은 브라우저의 특정 기능들을 사용할 수 있는지 없는지를 정하는 헤더예요. 악성 웹사이트가 사용자의 동의 없이 기능을 사용하는 것을 막을 수 있어요.
  • 설정 예시:
    Permissions-Policy: camera=(), geolocation=(self)
    • camera=(): 이 웹사이트에서는 카메라를 사용할 수 없도록 해요.
    • geolocation=(self): 이 웹사이트 자체(self)에서만 위치 정보(geolocation)를 사용할 수 있도록 해요. 다른 외부 스크립트가 마음대로 위치 정보를 가져가는 것을 막아요.

3-6. Content-Security-Policy (CSP)

  • 역할: 웹사이트에서 불러오는 스크립트, 스타일, 이미지 같은 모든 자원들이 어떤 출처(도메인)에서만 허용될지를 아주 세밀하게 제어할 수 있는 가장 강력한 보안 헤더 중 하나예요. 크로스 사이트 스크립팅(XSS) 공격 같은 것을 막는 데 효과적이에요.
  • 설정 예시:
    Content-Security-Policy: default-src 'self'; img-src 'self' https://cdn.example.com; script-src 'self';
    • default-src 'self': 기본적으로 모든 자원은 '우리 웹사이트(self)'에서만 불러올 수 있도록 해요.
    • img-src 'self' https://cdn.example.com: 이미지는 우리 웹사이트와 https://cdn.example.com이라는 CDN에서만 불러올 수 있도록 해요.
    • script-src 'self': 스크립트는 우리 웹사이트에서만 불러올 수 있도록 해요.

4. 데이터 암호화 전략: 꼼꼼하게 잠그기

데이터는 두 가지 주요 시점에서 암호화가 필요해요. 하나는 데이터를 주고받을 때이고, 다른 하나는 데이터를 저장해 둘 때예요.

4-1. 전송 중 암호화 (In Transit)

  • 필수: HTTPS/TLS를 사용하는 것이 핵심이에요. 웹 브라우저와 서버 간에 데이터가 이동하는 동안 아무도 훔쳐보지 못하도록 암호화하는 거죠.
  • TLS 버전: 위에서 설명했듯이, TLS 1.2 이상을 사용하는 것이 중요하고, 최신 버전인 TLS 1.3은 보안과 성능 면에서 가장 뛰어나요.

4-2. 저장 시 암호화 (At Rest)

  • 데이터베이스 암호화: 웹사이트에서 사용하는 데이터베이스에 저장된 모든 데이터를 암호화하는 거예요. TDE(Transparent Data Encryption) 같은 기술을 사용하면 데이터베이스에 저장된 데이터 자체를 암호화해서, 만약 데이터베이스 파일이 유출되더라도 내용을 알 수 없게 만들 수 있어요.
  • 필드 암호화: 주민등록번호, 계좌번호, 전화번호처럼 특히 민감한 정보는 데이터베이스 전체를 암호화하는 것 외에도 해당 필드만 따로 암호화해서 저장하는 것을 고려할 수 있어요.
  • 암호화 알고리즘: 데이터를 암호화할 때는 AES-256, RSA-2048처럼 이미 검증되고 널리 사용되는 강력한 암호화 방식을 사용해야 해요.

Tip: 비밀번호는 절대로 원래 모습 그대로(평문) 저장하면 안 돼요! bcrypt, Argon2처럼 강력한 해시 함수를 사용해서 비밀번호를 암호화된 형태로 저장해야 해요. 이렇게 하면 만약 데이터베이스가 털려도 사용자 비밀번호가 바로 유출되지 않아요.

부록: 더 깊이 알아보기

A. 보안 헤더 Express.js에서 쉽게 설정하기

Node.js의 Express.js를 사용한다면, 다음과 같이 미들웨어를 통해 보안 헤더를 한 번에 설정할 수 있어요.

app.use((req, res, next) => {
  res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload');
  res.setHeader('X-Frame-Options', 'DENY');
  res.setHeader('X-Content-Type-Options', 'nosniff');
  res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin');
  res.setHeader('Permissions-Policy', 'camera=(), geolocation=(self)');
  // Content-Security-Policy는 내용이 길어져 별도의 모듈을 사용하는 것이 좋아요.
  next();
});

B. 암호화에 유용한 도구들

  • OpenSSL: SSL/TLS 인증서를 만들거나, 웹사이트의 TLS 설정을 테스트할 때 유용하게 쓰이는 강력한 도구예요.
  • bcrypt, argon2: 비밀번호를 안전하게 암호화(해시)할 때 사용하는 라이브러리예요.
  • Vault: 민감한 정보(비밀키, API 키, 인증서 등)를 안전하게 관리하고 배포하는 데 사용되는 도구예요.

C. 용어 정리: SSL vs TLS (더 자세히 알아볼까요?)

많은 사람이 SSL과 TLS를 섞어 쓰는 이유가 뭘까요? 그리고 이 둘은 정확히 어떻게 다른 걸까요?

역사적 배경

  • SSL 1.0: 넷스케이프에서 개발했지만, 실제로 공개되지 않은 베타 버전이에요.
  • SSL 2.0 (1995년): 처음으로 공개된 버전이지만, 여러 보안 취약점이 발견되어 빠르게 사라졌어요.
  • SSL 3.0 (1996년): 보안이 많이 개선되었지만, POODLE 공격 같은 새로운 취약점 때문에 지금은 더 이상 사용하지 않아요.
  • TLS 1.0 (1999년): SSL 3.0을 기반으로 만들어졌고, 이름만 TLS로 바뀌었을 뿐 내부적으로는 SSL 3.0과 비슷해요. 호환성을 위해 이름만 바뀐 초기 TLS 버전이죠.
  • TLS 1.1 (2006년): 몇 가지 보안 문제가 해결되었어요.
  • TLS 1.2 (2008년): 지금 가장 널리 쓰이는 버전으로, SHA-256 같은 더 강력한 암호화 방식을 지원하기 시작했어요. 대부분의 웹사이트에서 표준으로 사용하고 있어요.
  • TLS 1.3 (2018년): 가장 최신 버전으로, 데이터를 주고받기 시작하는 과정(핸드셰이크)을 훨씬 짧게 만들어서 속도를 높였고, 보안적으로 취약한 암호화 방식들을 아예 없애버려서 보안성과 성능을 동시에 잡았어요.

주요 차이점

  1. 버전 협상: 웹 브라우저와 서버가 서로 어떤 TLS 버전을 지원하는지 확인하고, 가장 안전하고 최신 버전을 자동으로 선택해서 사용해요.
  2. 데이터 주고받는 과정(핸드셰이크) 구조: TLS 1.3은 웹 브라우저와 서버가 연결을 맺는 단계를 한 번(1-RTT)으로 줄여서 연결 속도가 훨씬 빨라졌어요.
  3. 암호화 방식: 오래된 SSL 3.0과 TLS 1.0은 약한 암호화 방식도 허용했지만, TLS 1.2/1.3은 GCM, ChaCha20-Poly1305처럼 강력하고 안전한 암호화 방식만 사용하도록 강제해요.
  4. 보안 강화: TLS 1.2부터는 데이터의 변조를 막는 기능이 강화되었고, TLS 1.3에서는 모든 데이터가 암호화되어 보안성이 크게 좋아졌어요.
  5. 암호화 스위트 축소: TLS 1.3은 안전하지 않은 암호화 방식들을 제거하고, 웹 브라우저가 이전에 방문했던 사이트에 더 빠르게 접속할 수 있도록 0-RTT 모드를 기본으로 지원해요.

실무에서 적용하는 팁

  • 여러분 서버에서 SSLv2, SSLv3, TLS 1.0, TLS 1.1은 아예 사용하지 못하도록 설정하고, TLSv1.2와 TLSv1.3만 허용해야 해요.
  • 암호화 방식(Cipher 스위트)도 OWASP나 Mozilla에서 권장하는 최신 기준에 맞춰 설정하세요.
  • 정기적으로 SSL Labs나 testssl.sh 같은 온라인 도구를 사용해서 여러분의 웹사이트 TLS 설정이 제대로 되어 있는지, 혹시 취약점은 없는지 꼭 점검해야 해요.
  • 발급받은 인증서가 만료되지 않았는지, 그리고 인증서 발급 기관(CA)이 신뢰할 수 있는 곳인지도 주기적으로 확인하는 게 좋아요.

D. 왜 아직도 'SSL'이라는 말을 많이 쓸까요? (용어 혼동의 역사)

기술적으로는 'TLS'가 맞는 표현인데 왜 아직도 'SSL'이라는 말을 많이 쓸까요? 몇 가지 이유가 있어요.

  1. 오랜 습관: 넷스케이프가 1990년대 초에 처음 개발한 암호화 기술이 'SSL'이었어요. 시간이 지나 'TLS'로 발전했지만, 사람들은 이미 'SSL'이라는 이름에 익숙해져 버렸죠. 한번 굳어진 용어는 쉽게 바뀌지 않아요.
  2. 인증서 판매 회사의 마케팅: 인증서를 판매하는 회사들은 처음부터 "SSL 인증서"라는 이름을 사용해서 마케팅을 해왔어요. 이 이름이 더 친숙하고, 오랫동안 사용되었기 때문에 지금도 많은 곳에서 "SSL 인증서"라는 브랜드를 고수하고 있어요.
  3. 기술 문서에서의 혼용: 웹 호스팅 가이드, 서버 관리 문서, 온라인 튜토리얼 등 많은 기술 문서에서도 정확한 명칭 대신 "SSL 인증서"라는 용어를 그대로 사용하는 경우가 많아요. 그래서 "SSL 인증서 설치"라고 검색하면 실제로는 TLS 1.2/1.3용 인증서 설치 방법이 나오는 것을 볼 수 있죠.

정리: '프로토콜 자체'를 이야기할 때는 TLS라는 용어를 쓰는 것이 정확해요. 하지만 '인증서'를 이야기할 때는 오랜 관습 때문에 SSL 인증서라는 표현도 많이 쓰인다는 점을 이해하시면 됩니다. 중요한 건 용어보다는 실제로 TLS 1.2 이상의 최신 버전을 적용하는 것이라는 점을 기억해주세요!

profile
Kylie
올해보단 낫겠지....
이전 포스트

XSS 완전정복 & 입력 검증으로 안전한 웹 만들기

다음 포스트

웹 접근성과 SEO

0개의 댓글