Madison Digital Garden

Search

SearchSearch

11. TLS

Apr 15, 2024, 7 min read

서울대학교 컴퓨터공학과 권태경 교수님의 "Topics in Computer Networks" 강의를 필기한 내용입니다.

다소 잘못된 내용과 구어적 표현 이 포함되어 있을 수 있습니다.

NOTE: 놓친게 많으니 다시 해야할듯

복습

  • namespace 의 각 level 마다 ksk 와 zsk 가 있다
  • dnsrec 과 client 간에는 encryption 이 되어있지 않다
    • 그래서 이 사이를 monitor 해서 client 가 어떤 도메인을 요청하는지 알아내 여러 정보를 빼낼 수 있다
    • 여기에 그래서 tls 나 https 를 넣어 DoT / DoH 를 사용할 수 있다
  • dnssec 의 trust chain 을 다 검증하는 것은 오버헤드가 있기 때문에 dnsrec 한테 부하가 걸린다
  • ns record 의 소유권은 사실은 subdomain 에 있기 때문에 ns record 자체는 상위 domain 에 있지만 소유권이 없어서 이것을 서명해 rrsig 로 만들지는 못한다
  • dnssec 과 마찬가지로 dane 또한 아주 배포율이 저조하다
  • dnssec 이 배포율이 적은 이유
    • registry: nameserver 를 운영하며 namespace 를 관리하는 기업
    • registrar: registry 와 client 를 연결하는 대행사 (가비아 등)
    • 30% 에 가까운 namespace 가 dnskey 는 있지만 상위 namespace 에 ds record 를 업로드하지는 않았다고 한다
    • registrar 가 직접 ds 를 registry 에 업로드할 수도 있지만 그런 경우는 극히 적었고
    • 대부분은 ds upload 를 domain owner 인 client 가 해야 하는데 그런 경우도 적었고
    • 직접 ds upload 를 할 수 있는 방법이 있어도 error 에 취약하다

TLS

  • netscape 에서 먼저 ssl 을 만들었고 이것의 보안취약점을 보안해서 ietf 에서 tls 로 표준 재정했다더라
  • tls 의 구조
    • record: ??
    • handshake:
      • tls 는 1.0 부터 1.3 까지 4개의 버전이 있기 때문에 버전을 맞추는 것, 그리고 암호 알고리즘 버전도 맞춘다
      • public key 를 이용해 shared secret 을 공유
      • 이 shared secret 으로 동일한 symmetric key 를 생성해 이것으로 통신
      • ClientHello
        • client 가 사용가능한 protocol, alg version 을 server 에게 제시하는 것
      • ServerHello
        • server 는 clientHello 과 자신이 사용할 수 있는 버전들을 비교해 server 와 client 가 모두 사용할 수 있는 가장 최신의 protocol version, 가장 강력한 alg 를 선택해 답장
      • Certificate, ServerKeyExchange
        • server 는 인증서와 (가능하다면?) public key 를 보낸다? 이것은 optional 하다?
        • 왜?
      • ClientKeyExchange?
      • ServerHelloDone?
      • serverhellodone 을 받으면 client 는 pre-master secret (PMS) 를 server 에 server pubkey 로 암호화하여 보낸다
      • server 는 이것을 server privkey 로 복호화하면 동일한 pms 를 얻게 되는 것
      • pms, “master secret” string literal, client hello 에 들어있던 random num, server hello 에 들어있던 random num 을 prf 를 돌려서 master secret 을 생성
      • 그리고 prf 를 한번더 돌린다?
      • prf 를 한번 더 돌리는 이유는 pkc alg 마다 pms 의 길이는 달라질 수 있지만 master secret 의 길이는 일정하게 유지하기 위해?
    • Alert
      • error detection 과정
    • ?? 뭐 하나 더있는데
  • handshake 의 모든 message 는 plaintext 이다
    • message 가 encrypt 되기 전까지가 handshake 임?

TLS Rollback Attack (Downgrade Attack)

  • Client hello 는 plaintext 이기 때문에 중간 attacker 가 이것을 볼 수 있는데
  • attacker 가 중간에서 client 가 사용할 수 있는 버전을 낮춰서 server 한테 보내서 그것으로 통신을 하게 만들고
  • 낮은 버전의 tls 에는 보안 취약점이 있기 때문에 attacker 가 이 취약점을 노려 그 안의 내용을 확인한다
  • 이것은 finish message 를 이용해 보완할 수 있다 - encryption 이 시작된 직후 모든 plaintext msg 를 hash 해 서로 검증하는 절차를 거칠 수 있다?

Forward Secrecy

  • 일단 모든 통신 내용을 떠서 보관해놨다가
  • 나중에 privkey 가 유출되는 등의 사고가 있으면
  • 이것으로 모든 내용을 복호화해서 보는 것
  • 이를 해결하기 위해서는 DHE (Diffie-Hellman Ephimeral) 이나 ECDHE 등의 세션 기반의 암호를 사용할 수 있다
    • server 는 pubkey 로 g^s mod p 를 보내고 (+ Ks- 로 서명해서?)
    • client 는 pubkey 로 g^c^s mod p 를 보낼때
    • server 가 s 를 추후에 삭제해버리면 이런 ephimeral 을 성취할 수 있다?
  • DH_RSA
    • 키쌍은 DH 로 만들고 CA Cert 는 RSA 로 만드는 것?
    • 이 방법은 tls 1.2 까진 사용됐지만 1.3 부턴 사라져서 DHE_RSA 이 쓰인다?

TLS 1.3

  • 2RTT 를 1RTT 로 줄였다
    • 이전에는 hello, key exchange 두번의 round trip 이 있었지만
    • 1.3 에서는
      • hello 에서 모든 secret 교환을 마쳐 hello 다음 바로 finish 로 들어갈 수 있다?
  • 0-RTT 도 가능하다
    • session resumption? 이미 교환된 secret 으로 통신을 이어나가는것?
    • replay attack 이 가능하다?
  • 보안취약점이 있는 alg 는 삭제했다

Graph View

Backlinks