DNS-기반 네임 개체 인증(DANE)
DNS-기반 네임 개체인증은 일반적으로 TLS(전송 계층 보안)에서 쓰고 있는 X.509 인증서를 사용하기 위한 프로토콜이다.
DNSSEC을 이용해 DNS 네임에 붙인다.
글로벌 PKI 시스템의 CA 사용 취약점 해소 방안으로 제시 되었다.
CA 시스템 보안에 종속 되는걸 탈피하고 DNSSEC가 제공하는 보안으로 대체 되었다
TLSA 레코드
DANE에서는 새로운 DNS 레코드 유형인 TLSA를 정의 하였다.
이는 SSL/TLS(전송 계층 보안) 인증서를 안전하게 인증할 수 있다.
목적
- 어떤 CA가 인증서를 보증하는지 어떤 특정 PKIX 종단-개체 인증서가 유효한지에 대한 제약 사항을 구체화한다
- 서비스 인증서나 CA가 DNS 자체에서 직접 인증 될 수 있는지 구체화
TLSA RR
아래는 TLSA RR 전송 형식이다.
TLSA RR로 인증서 발행과 배달을 주어진 도메인에 묶을 수 있다.
서버 도메인 소유자는 TLSA 자원 레코드를 생성해서 인증서와 공개 키를 식별한다.
클라이언트가 TLS 협상 중 X.509 인증서를 수신하면, 해당 도메인의 TLSA RR을 찾고, 클라이언트 인증서 검증 절차의 일부로 TLSA 데이터를 인증서에 매치시킨다
TLSA RR의 인증서 활용 필드는 4개의 모델이 있다
- PKIX-TA(CA 제약: CA constraint)
- PKIX-EE(서비스 인증서 제약: service certificate constraint)
- DANE-TA(신뢰 닻 확인: trust anchor assertion)
- DANE-EE(도메인-발행 인증서: domain-issued certificate)
선택자 필드는 전체 인증서가 매치되는지, 공개 키 값만 매치 되는지를 나타낸다
TLS 협상에서 제시된 인증서와 TLSA RR의 인증서를 매치한다.
매치 유형 필드는 어떻게 인증서가 매치되는지를 나타낸다.
옵션으로 정확한 매치, SHA-256, 해시 매치 등이 있다.
인증서 연관 데이터는 16 진수 형태의 미처리 된 인증서 데이터이다.
SMTP를 위한 DANE 활용
TLS 상의 SMTP와 DANE을 이용하면, STARTTLS가 제공 되는 것처럼, 전체적으로 더 안전한 이메일 전송을 할 수 있다
- DANE
- 사용자 메일 클라이언트가 통신하는 SMTP 제출 서버의 인증서를 인증 할 수 있다
- SMTP 서버들 간의 TLS 연결을 인증 할 수 있다.
- SMTP
- STARTTLS를 확장을 이용해서, TLS 상에서 SMTP를 구동할 수 있다.
- 즉 전체 이메일 메시지와 SMTP 봉투를 암호화 할 수 있다.
SMTP의 취약점
- 공격자가 TLS 기능에 대한 광고를 못하게 하고, 연결에 TLS를 사용하지 못하게 한다
- TLS 연결은 종종 인증하지 않는다.
DANE은 위 2가지 취약점을 다루고 있다.
- 도메인은 TLSA RR이 존재하는지를 보고 암호가 반드시 수행 되어야만 한다는 걸 알 수 있다.
- 도메인은 DNSSEC 서명된 TLSA RR을 활용한 TLS 연결 설정에 쓰이는 인증서를 인증 할 수 있다
Secure MIME DNSSEC 활용
DNSSEC를 S/MIME과 같이 이용하면 DANE 기능과 유사한 방법으로 이메일 전송을 더 안전하게 할 수 있다
S/MIME 메시지는 종종 메시지 송신자 인증을 돕거나 응답으로온 메시지를 암호화하는 데 사용하는 인증서를 포함한다
이 기능은 수신하는 MUA가 송신자라고 주장하는 자와 연결된 인증서를 검증할 것을 요구한다
SMIMEA RR은 이 검증 수행을 안전하게 할 수 있는 수단을 제공한다
SMIMEA RR
TLSA RR과 동일한 형식과 컨텐츠를 가지며 기능도 동일하다
하지만, SMIMEA RR은 메시지 내용에 있는 이메일 주소를 처리하기 위해 MUA가 필요할 때 동작한다
이는 TLSA RR이 처리하는 외부 SMTP 봉투에 쓰인 도메인 이름을 처리하는 방식과 다르다.
부족한 점이나 잘못 된 점을 알려주시면 시정하겠습니다 :>
'Computer Science > 네트워크' 카테고리의 다른 글
하트 비트 프로토콜 (0) | 2023.06.14 |
---|---|
IPsec (0) | 2023.06.08 |
DNS (0) | 2023.06.03 |
RFC 5322 (0) | 2023.06.03 |
SMTP (0) | 2023.06.03 |