• 대칭키 암호화와 비대칭키 암호화의 장단점은 무엇인가요?
• HTTPS에서 대칭키와 비대칭키가 사용되는 시점은 언제인가요?
• SSL/TLS 인증서와 공개키의 관계는 무엇인가요?
• SSL Handshake 과정에서 키 교환은 어떻게 이루어지나요?
• 왜 HTTPS는 두 가지 암호화 방식을 함께 사용하나요?

• 암호화 방식은 키 사용 방법에 따라 대칭키와 비대칭키로 구분됩니다 🔐

대칭키 암호화 (Symmetric Encryption)

• 송신자와 수신자가 동일한 키를 공유하여 암호화/복호화하는 방식
• 하나의 키로 암호화와 복호화를 모두 수행
• 예시: AES, DES 알고리즘

비대칭키 암호화 (Asymmetric Encryption)

• 공개키(Public Key)와 개인키(Private Key) 한 쌍을 사용하는 방식

• 공개키로 암호화하면 개인키로만 복호화 가능

• 개인키로 암호화하면 공개키로만 복호화 가능 (디지털 서명)

• 예시: RSA, ECC 알고리즘

• 꼬리질문: 대칭키 암호화와 비대칭키 암호화의 장단점은 무엇인가요?

  • 대칭키 암호화
    • 장점: 암호화/복호화 속도가 매우 빠름 ⚡, 알고리즘이 단순함
    • 단점: 키 교환의 어려움 😰, 키 관리 복잡성 증가
  • 비대칭키 암호화
    • 장점: 안전한 키 교환 가능 🛡️, 디지털 서명 지원, 키 관리 용이
    • 단점: 암호화/복호화 속도가 느림 🐌, 알고리즘 복잡성

• 꼬리질문: HTTPS에서 대칭키와 비대칭키가 사용되는 시점은 언제인가요?

  • 비대칭키 사용 시점 (SSL Handshake 단계)
    • 서버 인증 과정에서 인증서 검증
    • 대칭키(세션키)를 안전하게 교환할 때
    • 디지털 서명으로 메시지 무결성 검증
  • 대칭키 사용 시점 (실제 데이터 통신)
    • Handshake 완료 후 모든 HTTP 데이터 암호화
    • 웹페이지 내용, 이미지, API 응답 등 실제 통신 데이터

• 꼬리질문: SSL/TLS 인증서와 공개키의 관계는 무엇인가요?

  • 인증서(Certificate): 서버의 공개키를 담고 있는 디지털 문서 📄
    • 서버의 신원 정보 (도메인명, 조직명 등)
    • 서버의 공개키
    • CA(인증기관)의 디지털 서명
  • 공개키: 인증서 내부에 포함된 암호화 키
    • 클라이언트가 대칭키를 암호화할 때 사용
    • 서버만이 대응하는 개인키를 가지고 있음

• 꼬리질문: SSL Handshake 과정에서 키 교환은 어떻게 이루어지나요?

  • 1단계: 클라이언트가 Client Hello 메시지 전송 (지원 암호화 방식 목록)
  • 2단계: 서버가 Server Hello + 인증서 전송 (공개키 포함)
  • 3단계: 클라이언트가 인증서 검증 후 대칭키 생성
    • 서버의 공개키로 대칭키를 암호화하여 전송
  • 4단계: 서버가 개인키로 대칭키 복호화
  • 5단계: 양쪽 모두 ChangeCipherSpec + Finished 메시지 교환
  • 이후 모든 통신은 공유된 대칭키로 암호화/복호화 🔄

• 꼬리질문: 왜 HTTPS는 두 가지 암호화 방식을 함께 사용하나요?

  • 하이브리드 방식의 장점
    • 비대칭키: 안전한 키 교환과 서버 인증 담당 🛡️
    • 대칭키: 빠른 대용량 데이터 암호화 담당 ⚡
  • 성능과 보안의 최적 균형
    • 비대칭키만 사용하면 통신 속도가 매우 느려짐
    • 대칭키만 사용하면 안전한 키 교환이 불가능
    • 두 방식의 장점만 취하여 실용적인 보안 통신 구현

• SameSite 속성이 없는 경우 어떤 문제가 발생할 수 있나요?
• SameSite=Strict와 SameSite=Lax의 실제 동작 차이는 무엇인가요?
• SameSite=None을 사용할 때 주의할 점은 무엇인가요?
• 브라우저별 SameSite 기본값은 어떻게 다른가요?

• SameSite 쿠키 속성은 CSRF(Cross-Site Request Forgery) 공격을 방어하고 사용자 프라이버시를 보호하기 위해 설정합니다 🛡️

  • 크로스 사이트 요청에서 쿠키가 전송되는 것을 제어하여 악의적인 웹사이트가 사용자의 인증 쿠키를 도용하는 것을 방지
  • 제3자 추적을 제한하여 사용자 프라이버시 향상

• SameSite 속성의 세 가지 옵션 📋

  • Strict: 가장 엄격한 보안 수준

    • 동일 사이트 요청에서만 쿠키 전송
    • 다른 사이트에서 링크를 클릭해 방문해도 쿠키가 전송되지 않음
    • 예시:

    Set-Cookie: sessionid=abcdef123456; SameSite=Strict

  • Lax: 균형잡힌 보안 수준 (현재 브라우저 기본값)

    • 동일 사이트 요청과 안전한 HTTP 메서드(GET)를 사용한 최상위 탐색에서만 쿠키 전송
    • 크로스 사이트 POST 요청에서는 쿠키 제외
    • 예시:

    Set-Cookie: userpref=darkmode; SameSite=Lax

  • None: 모든 요청에서 쿠키 전송 허용

    • 크로스 사이트 요청에서도 쿠키 전송
    • 반드시 Secure 속성과 함께 사용해야 함 (HTTPS 필수)
    • 예시:

    Set-Cookie: tracking=xyz; SameSite=None; Secure

• 실제 사용 예시와 시나리오 💡

  • 인증 세션 쿠키 (SameSite=Strict):

    Set-Cookie: __Host-BMOSESSIONID=YnVuemlsbGE=; Max-Age=2592000; Path=/; Secure; HttpOnly; SameSite=Strict
    • 은행이나 결제 시스템처럼 높은 보안이 필요한 경우
    • CSRF 공격에 대한 최대 보호 제공
  • 일반 웹사이트 세션 (SameSite=Lax):

    Set-Cookie: __Secure-MOZSESSIONID=7307d70a86bd4ab5a00499762; Max-Age=2592000; Domain=example.org; Path=/; Secure; HttpOnly; SameSite=Lax
    • 대부분의 웹 애플리케이션에 적합
    • 외부 링크를 통한 접속 시에도 로그인 상태 유지
  • 제3자 위젯/임베드 (SameSite=None):

    Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly
    • 다른 사이트에 임베드되는 위젯이나 iframe
    • 크로스 사이트 기능이 필수적인 경우

• 꼬리질문: SameSite 속성이 없는 경우 어떤 문제가 발생할 수 있나요?

  • CSRF 공격에 취약해짐
    • 악의적인 웹사이트가 사용자 모르게 인증된 요청을 전송 가능
    • 예: 은행 송금, 비밀번호 변경 등의 민감한 작업 수행
  • 제3자 추적 가능
    • 광고 네트워크나 분석 도구가 여러 사이트에서 사용자 추적
  • 최신 브라우저는 SameSite 미지정 시 기본값을 Lax로 처리

• 꼬리질문: SameSite=Strict와 SameSite=Lax의 실제 동작 차이는 무엇인가요?

  • Strict 동작 예시:
    • 사용자가 구글 검색 결과에서 은행 사이트 링크 클릭
    • 은행 사이트 접속 시 로그인 쿠키 전송 안 됨 → 로그아웃 상태로 표시
    • 사용자가 다시 로그인해야 함
  • Lax 동작 예시:
    • 같은 상황에서 GET 요청으로 이동하므로 쿠키 전송됨
    • 로그인 상태 유지됨
    • 하지만 악의적인 사이트의 form POST 요청에는 쿠키 전송 안 됨

• 꼬리질문: SameSite=None을 사용할 때 주의할 점은 무엇인가요?

  • 필수 요구사항:
    • 반드시 Secure 속성 포함 (HTTPS 전용)
    • 잘못된 예: Set-Cookie: tracking=xyz; SameSite=None ❌
    • 올바른 예: Set-Cookie: tracking=xyz; SameSite=None; Secure ✅
  • 보안 고려사항:
    • CSRF 공격에 노출될 수 있으므로 추가 보안 조치 필요
    • CSRF 토큰 사용 권장
    • 민감한 작업에는 사용하지 않기
  • 호환성 문제:
    • 일부 구형 브라우저는 SameSite=None을 인식하지 못함
    • User-Agent 확인하여 호환성 처리 필요

• 꼬리질문: 브라우저별 SameSite 기본값은 어떻게 다른가요?

  • 최신 브라우저 (Chrome 80+, Firefox 96+, Safari 15+):
    • SameSite 미지정 시 Lax가 기본값
    • 보안 강화를 위한 변경사항
  • 구형 브라우저:
    • SameSite 미지정 시 None처럼 동작
    • 모든 크로스 사이트 요청에 쿠키 전송
  • 브라우저별 구현 차이:
    • Chrome: 2분간의 유예 기간 제공 (Lax+POST)
    • Safari: 더 엄격한 추적 방지 정책 적용
    • Firefox: 표준 스펙에 가장 가깝게 구현