• 대칭키 암호화와 비대칭키 암호화의 장단점은 무엇인가요?
• 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: 표준 스펙에 가장 가깝게 구현

• 파일 디스크립터의 3단계 테이블 구조에 대해 설명해주세요.
• sk_buff 구조체의 역할과 zero-copy 최적화에 대해 설명해주세요.
• 네트워크 패킷이 하드웨어까지 전달되는 과정을 설명해주세요.
• 하드웨어 인터럽트에서 소프트웨어 인터럽트로 전환되는 이유는 무엇인가요?
• DMA와 링 버퍼를 사용하는 이유와 동작 과정을 설명해주세요.

✅ 1단계: Application에서 소켓 생성 및 파일 디스크립터 할당

• socket() 시스템 콜 호출 시 운영체제가 통신 도메인에서 바인딩되지 않은 소켓 생성
• 커널이 가장 낮은 사용되지 않은 파일 디스크립터 번호를 할당 (0,1,2 이후 순차적)
• 파일 디스크립터는 프로세스별로 고유한 정수 식별자로 작동

✅ 2단계: 다중 레벨 테이블을 통한 소켓 관리

• 프로세스별 파일 디스크립터 테이블 → 시스템 전체 파일 테이블 → inode 테이블
• Unix에서는 "모든 것이 파일"이므로 소켓도 파일로 취급
• 각 테이블이 포인터로 연결되어 효율적인 I/O 작업 지원

✅ 3단계: 데이터 전송 시 커널 스택 처리

• write()/send() 시스템 콜이 __sock_sendmsg()로 수렴
• sockfd_lookup()으로 파일 디스크립터 검증 후 소켓 구조체 반환
• 사용자 데이터를 sk_buff(Socket Kernel Buffer)로 캡슐화

✅ 4단계: 네트워크 스택을 통한 프로토콜 처리

• TCP → IP → Ethernet 순으로 각 계층이 헤더 추가
• sk_buff는 커널 내부에서 데이터 복사 없이 포인터만 조작하여 성능 최적화
• 네트워크 필터링(방화벽, NAT) 및 라우팅 결정 수행

✅ 5단계: 하드웨어 전송

• 큐잉 디스플린(Qdisc)을 통해 패킷 스케줄링
• DMA(Direct Memory Access)를 통해 CPU 개입 없이 NIC로 직접 데이터 전송
• 링 버퍼(Ring Buffer)를 사용하여 효율적인 패킷 관리

꼬리질문: 파일 디스크립터의 3단계 테이블 구조에 대해 설명해주세요.

✅ 1단계: 프로세스별 파일 디스크립터 테이블

• 각 프로세스마다 독립적인 테이블 존재 (커널 공간에 위치)
• 파일 디스크립터(정수)가 인덱스 역할
• 시스템 전체 파일 테이블로의 포인터와 플래그 정보 저장

✅ 2단계: 시스템 전체 파일 테이블

• 모든 프로세스가 공유하는 열린 파일 정보
• 파일 열기 모드(읽기/쓰기/추가), 파일 오프셋 등 저장
• inode 테이블로의 포인터 보유

✅ 3단계: inode 테이블

• 실제 파일의 메타데이터 저장
• 파일 크기, 권한, 생성/수정 시간 등 포함
• 디스크에서 실제 데이터 위치 정보 보유

꼬리질문: sk_buff 구조체의 역할과 zero-copy 최적화에 대해 설명해주세요. ✅ sk_buff의 핵심 역할

• 네트워크 패킷과 모든 메타데이터를 담는 컨테이너 📦
• 헤더/페이로드 정보, 프로토콜 정보, 네트워크 장치 정보 포함
• 각 프로토콜 계층을 통과하며 상태 추적

✅ Zero-Copy 최적화 메커니즘

• 사용자 공간 → 커널 공간: 불가피한 1회 복사 발생 (보안상 필요)
• 커널 내부: 진짜 Zero-Copy 적용 ⚡
  • 패킷 데이터는 한 곳에 고정, 포인터만 조작
  • TCP/IP/Ethernet 헤더 추가 시 데이터 복사 없음
  • headroom에 헤더 추가하고 data 포인터만 이동
  • mac_header, network_header, transport_header로 각 계층 헤더 위치 추적
• 성능 향상: 커널 내 메모리 복사 오버헤드 제거로 초당 수백만 패킷 처리 🚀

꼬리질문: 네트워크 패킷이 하드웨어까지 전달되는 과정을 설명해주세요. ✅ 커널 내부 처리 과정

• dev_queue_xmit()이 패킷을 디바이스 큐에 삽입
• 큐잉 디스플린이 패킷 스케줄링 및 우선순위 관리
• dev_hard_start_xmit()이 실제 하드웨어 전송 명령 생성

✅ 하드웨어 레벨 전송

• DMA 엔진이 sk_buff 데이터를 링 버퍼의 디스크립터로 전송
• NIC가 링 버퍼에서 패킷을 읽어 물리적 네트워크로 송출 🚀
• 전 과정에서 CPU 개입 최소화로 성능 향상

꼬리질문: 하드웨어 인터럽트에서 소프트웨어 인터럽트로 전환되는 이유는 무엇인가요? ✅ 하드웨어 인터럽트(HardIRQ)의 문제점

• 다른 작업을 중단시키며 자신도 인터럽트될 수 없음 ⛔
• CPU에 매우 높은 비용 발생
• 최소한의 작업만 수행하고 빠르게 종료해야 함

✅ 소프트웨어 인터럽트(SoftIRQ)의 장점

• CPU 비용이 훨씬 저렴하고 효율적 💰
• 인터럽트 핸들러가 하드웨어 인터럽트를 마스킹 후 활용
• NAPI 서브시스템을 통한 폴링 방식으로 대량 패킷 처리
• ksoftirqd 스레드가 CPU별로 독립적인 큐 관리

꼬리질문: DMA와 링 버퍼를 사용하는 이유와 동작 과정을 설명해주세요. ✅ DMA 사용 이유

• CPU 개입 없이 메모리와 하드웨어 간 직접 데이터 전송 ⚡
• CPU가 다른 작업에 집중할 수 있어 전체 시스템 성능 향상
• 고속 네트워크에서 필수적인 기술

✅ 링 버퍼 동작 과정

• 초기화: 커널 부팅 시 CPU가 RX/TX 링 버퍼를 DMA 영역에 할당
• 디스크립터 생성: 실제 패킷 데이터 위치를 가리키는 포인터 구조체
• 전송 과정:
  • CPU가 NIC에 새 디스크립터 생성 알림
  • DMA가 디스크립터 정보를 가져와 패킷 데이터 위치 파악
  • 패킷 도착 시 DMA가 직접 링 버퍼에 데이터 기록
• 인터럽트 알림: NIC가 하드웨어 인터럽트로 새 패킷 도착을 CPU에 알림 📨

✅ 성능 최적화 효과

• 순환 버퍼 구조로 메모리 효율성 극대화
• CPU와 NIC 간 비동기 처리로 처리량 향상
• 오버플로우 시 기존 데이터 덮어쓰기로 메모리 안정성 확보