OpenVPN EC 대 ED: 이 이름들이 강도 사다리가 아닌 이유

ec, ed, ecdh, ecdsa, auth와 TLS 암호 목록을 한 프로필에 나란히 두면, 그 파일은 여섯 단계의 강도 다이얼처럼 보이기 시작합니다. 하지만 그렇지 않습니다. 각 이름은 서로 다른 질문에 답하며, 그중 하나에서 다른 두 프로필이 반드시 서로 더 강하거나 약한 것은 아닙니다. 이름을 하는 일에 따라 정렬하는 데 약 오 분이 걸리고, 사람들이 동작하는 구성에 가하는 나쁜 편집의 대부분을 막아 줍니다.

아래 정리는 혼란 그 자체에서 시작해, 바깥으로 나아가 여러분의 트래픽을 실제로 보호하는 것을 결정하는 프로필의 부분으로 향합니다. 각 절은 잘못된 읽기 하나씩을 다루고 그 이름이 실제로 무엇에 붙어 있는지 보여 줍니다.

두 글자, 두 개의 서로 다른 질문

가장 많은 논쟁을 부르는 짝은 EC와 ED이고, 그 논쟁은 보통 둘이 한 질문에 대한 경쟁하는 답이라고 가정합니다. 둘은 같은 축에 있지도 않습니다. EC는 수학의 한 계열, 곧 타원 곡선 암호를 설명하며, 안전성은 큰 유한체가 아니라 곡선 위의 이산 로그의 어려움에서 나옵니다.

ED는 그 계열 안의 곡선 모양을 설명합니다. Twisted Edwards 곡선은 속도와 여러 구현 실수에 대한 내성을 위해 선택된 표현이고, Ed25519는 사람들이 보통 가리키는 이름입니다. 곡선은 타원 곡선 암호의 경쟁자가 아니라 타원 곡선을 적는 한 방법입니다. ED를 "더 새롭고 더 강한 EC"로 읽는 것이 첫 번째 잘못된 길이고, 그 뒤의 모든 것도 같은 방향으로 틀리기 쉽습니다.

서명과 교환은 별개의 일

계열에 대한 질문이 정리되면, 남은 이름들은 서로를 절대 대신할 수 없는 두 열로 나뉩니다. 한 열은 서명하고, 다른 열은 공유 비밀에 합의합니다.

EdDSA와 ECDSA는 둘 다 서명하지만 키 형식이 다른 서로 다른 방식이므로, 한쪽을 위해 발급된 인증서는 다른 쪽으로 쓸 수 없습니다. EdDSA는 적은 수의 곡선 집합에 대해 정의되어 있고 P-256은 그중 하나가 아니므로, P-256 인증서는 ECDSA로 검증되고 Ed25519로는 결코 검증되지 않습니다.

교환 열에는 EdDH라는 이름의 대응물이 없습니다. Curve25519 키에 대한 일시적 합의는 X25519이고, 그것은 특정 곡선을 쓴 ECDH로 P-256의 경우와 똑같습니다. Ed25519는 엄밀히 서명 방식을 뜻하지만, 두 곡선이 관련되어 있기 때문에 이 이름은 교환에도 느슨하게 쓰이며, 서명에 쓰는 Edwards 형식과 X25519에 쓰는 Montgomery 형식이 같은 기저 군을 설명합니다.

EC 프로필에 dh 파일이 없는 이유

dh 파일에는 유한체 Diffie-Hellman용으로 미리 생성된 매개변수가 들어 있고, 그 매개변수가 존재하는 이유는 큰 소수와 생성자를 어디선가 가져와야 하기 때문입니다. 타원 곡선 교환에는 필요하지 않은데, 이름 붙은 곡선이 곧 매개변수 집합이고 양쪽이 이미 그것을 알고 있기 때문입니다. 이것이 EC 프로필이 그 지시자를 생략할 수 있는 전부의 이유입니다.

그 밖에는 현대적으로 보이는 프로필에도 dh 줄이 생기는 상황이 두 가지 있습니다. 첫째는 유한체 군을 실제로 협상하는 두 번째 리스너나 더 오래된 피어입니다. 둘째는 RSA 시대 템플릿에서 복사되어 지워지지 않은 잔여 텍스트입니다. 교환에 곡선을 지정하면서 여전히 2048비트 dh 파일을 읽는 프로필은 그래서 더 안전해지지 않으며, 쓰이지 않는 유물을 안고 있을 뿐입니다.

TLS 1.3은 이름에서 키 교환을 빼 버렸다

TLS_AES_256_GCM_SHA384와 TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384를 비교해 보면 짧은 이름이 하향처럼 보입니다. 이것은 이름 변경이고 이유는 구조적입니다. TLS 1.3은 정적 RSA와 유한체 Diffie-Hellman 키 교환을 제거했으므로 일시적 타원 곡선 교환이 PSK가 아닌 유일한 남은 선택지가 되었고, 모든 스위트에서 그것을 이름 붙이면 같은 사실을 열두 번 반복하는 셈입니다.

인증서 유형이 이름에서 사라진 것도 관련된 이유 때문입니다. 1.3에서는 인증서가 핸드셰이크 서명을 인증하고 키 합의를 인증하지 않으므로 더 이상 스위트를 고르지 않습니다. 구성에 1.3용 암호 목록이 따로 있는 것도 같은 이유로, 스위트는 이름이 바뀌고 재편되었을 뿐 약해진 것이 아닙니다.

한 가지 결과는 분명히 말할 가치가 있습니다. ECDHE는 키 교환 알고리즘이며 결코 암호가 아닙니다. "타원"이라고 설명되는 스위트는 두 피어가 어떻게 공유 키에 이르렀는지에 대해 무언가를 말하고, 그 뒤에 무엇이 페이로드를 암호화하는지에 대해서는 아무것도 말하지 않습니다.

auth는 패킷을 인증하고 페이로드를 인증하지 않는다

auth 지시자는 패킷을 인증하는 HMAC 다이제스트를 고르며, 그 역사적 기본값은 SHA1입니다. AEAD가 아닌 데이터 암호에서는 OpenVPN이 암호문에 대해 다이제스트를 계산해 덧붙이며, 이 암호화 후 MAC 배치가 패딩 조작을 비현실적으로 만듭니다.

여기서의 신화는 auth를 SHA512로 올리면 터널이 단단해진다는 것입니다. 그것은 암호화 강도를 높이지 않으며, 협상된 데이터 암호가 AES-256-GCM 같은 AEAD 모드라면 다이제스트는 데이터 패킷에 전혀 적용되지 않습니다. GCM 태그가 이미 그들을 인증하고, auth 값은 제어 채널의 HMAC과 아직 쓰이는 AEAD가 아닌 암호를 위해 남습니다.

그래서 이 지시자는 중요하지만, 파일에서의 위치가 암시하는 것보다 좁은 곳에서 중요합니다. 실제로 어떤 암호가 협상되었는지 확인하면 그것이 애초에 적용되는지 알 수 있습니다.

프로필은 순위가 아니라 열로 읽으라

세 질문이 계층을 깔끔하게 가르고, 각각은 협상된 세션의 다른 부분이 답합니다. 어떤 암호가 페이로드를 보호하는가. 어떤 태그나 다이제스트가 각 패킷을 보증하는가, 그리고 쓰이는 암호가 그것을 애초에 필요로 하는가. 누구의 인증서가 핸드셰이크를 닫았는가, 그리고 제어 채널은 추가로 tls-auth나 tls-crypt로 보호되는가.

EC나 ED 레이블 어디에도 그 세 가지 중 하나를 결정하는 것은 없고, 스위트 이름 하나만으로도 어느 것도 결정되지 않습니다. 협상된 결과만이 증거이므로, 어휘에서 강도를 추론하는 대신 그것을 읽으십시오:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

첫 번째 명령은 여러분의 인증서가 실제로 어느 서명 방식을 쓰는지 알려 주며, 이것이 ECDSA로 도는지 Ed25519로 도는지 아는 유일하게 신뢰할 수 있는 방법입니다. 두 번째는 클라이언트가 세션을 위해 기록한 제어 채널 줄을 TLS 버전과 정착한 스위트를 포함해 보여 줍니다. 프로필 수정이 이 두 출력 중 어느 것으로도 정당화되지 않는다면, 그것은 아마도 속성이 아니라 이름의 변경입니다.