tls-auth vs tls-crypt: OpenVPN에서 각각이 지키는 것

두 옵션 모두 공유 키 파일을 사용하고 둘 다 핸드셰이크 트래픽을 위조하기 어렵게 만들기 때문에 같은 기능의 두 이름으로 취급됩니다. 그렇지 않습니다. 하나는 제어 패킷에 서명하고, 다른 하나는 그것을 암호화까지 하며, 어느 쪽도 페이로드를 보호하는 암호와는 관계가 없습니다.

이 구분은 프로필이 연결되지 않을 때, 보안 검토가 키가 무엇을 지키는지 물을 때, 추가 파일이 터널을 어딘가 불분명하게 암호화한다고 누군가 가정할 때 중요합니다.

공유 키가 실제로 지키는 것

이 옵션들이 사용하는 키는 제어 채널에 속합니다: 매개변수를 협상하고 신원을 증명하며 데이터 키를 도출하는 교환. 이것은 핸드셰이크가 진행되기 전에 양쪽 끝이 모두 가져야 하는 사전 공유 비밀입니다. 신원 확인보다 앞에 있기 때문에 잘못된 키는 잘못된 비밀번호보다 더 일찍 대화를 멈춥니다. 이런 순서가 실패 방식이 그토록 조용한 이유를 설명합니다.

tls-auth는 그 비밀로 제어 패킷에 대한 HMAC을 계산합니다. 유효한 서명이 없는 패킷은 더 비싼 TLS 처리에 도달하기 전에 버려지며, 그래서 이 옵션은 TLS의 대체가 아니라 첫 번째 필터로 설명됩니다.

tls-crypt는 더 나아가 보호된 제어 트래픽을 인증할 뿐 아니라 암호화합니다. 인증서 내용, 협상된 암호 이름 및 기타 핸드셰이크 세부 정보는 더 이상 네트워크에서 보이지 않으며, 키가 없는 관찰자는 어떤 TLS 버전을 시도하는지조차 볼 수 없습니다. VPN 지문 노출을 우려하는 배포에서 이 특성이 그것을 선택하는 주된 이유입니다. 그래도 여전히 그룹 비밀이며 사용자별 자격 증명은 아닙니다.

어느 메커니즘도 신원을 발급하지 않습니다. 공유 키는 그룹 비밀이며, 그것을 가진 사람은 누구나 검사의 그 계층을 충족할 수 있습니다.

두 옵션이 다른 지점

관찰 가능한 차이는 관찰자가 무엇을 보느냐입니다. tls-auth에서는 핸드셰이크가 보이지만 키 없이는 검증할 수 없습니다. tls-crypt에서는 핸드셰이크가 키를 가지지 않은 사람에게는 불투명합니다.

구성도 다릅니다. tls-auth는 방향 값과 함께 사용되므로 한쪽은 키 자료의 절반을, 다른 쪽은 나머지 절반을 사용합니다. tls-crypt는 양방향에서 단일 키를 사용하므로 방향 지시문은 그 구성에 포함되지 않습니다.

최신 릴리스에서 두 옵션은 상호 배타적입니다. 프로필은 둘 중 하나만 가져야 하며 둘 다는 아닙니다. 서버와 클라이언트는 동일한 키 자료로 어느 것을 쓸지 합의해야 합니다. 오래된 지시문을 새것 옆에 남겨 두는 것은 흔한 마이그레이션 잔재입니다. 비활성 쪽을 제거해 다음 독자가 어느 계층이 실제로 유효한지 알 수 있게 하세요.

더 새로운 변형인 tls-crypt-v2는 각 클라이언트를 자체 래핑된 키에 묶어, 한 클라이언트를 폐기해도 그룹 키를 다시 발급할 필요가 없습니다. 알아 둘 가치는 있지만 다른 옵션이며 여기 있는 둘 중 어느 것의 동의어도 아닙니다.

불일치가 아무 일도 일어나지 않는 것처럼 보이는 이유

공유 자료가 일치하지 않으면 상대는 보낸 이에게 이유를 알리지 않고 패킷을 버립니다. 읽을 인증 오류가 없습니다. 패킷이 그것을 만들어 낼 계층에 도달한 적이 없기 때문입니다.

클라이언트는 다시 시도하고, 서버는 아무 말도 하지 않으며, 증상은 네트워크 문제처럼 보입니다. 그러면 사람들은 서비스를 다시 시작하거나, 계정 비밀번호를 다시 입력하거나, «테스트»를 위해 보호 지시문을 제거합니다. 이는 진단이 아니라 배포를 바꾸는 일입니다.

서버 로그에서는 마지막 재시도 줄이 아니라 첫 번째 패킷 수준 불만을 읽으세요. 양쪽이 동일한 키 자료로 같은 옵션을 갖고 있는지, 키 파일이 한쪽에서만 다시 생성되지 않았는지 확인하세요.

지시문을 제거하는 것은 안전한 수리가 아닙니다. 모든 클라이언트에 대해 보호 계층을 끄는 것이며, 그 후 터널이 동작한다는 것은 그 계층이 불일치였다는 것만 증명합니다.

여전히 따로 구성해야 하는 것

이 옵션들은 상대가 누구인지 검증하지 않습니다. 인증서 검증, 신뢰 앵커, 예상 서버 이름은 별도의 요구 사항으로 남으며, 공유 키가 있다고 해서 어느 것도 선택 사항이 되지 않습니다.

데이터 암호도 고르지 않습니다. 그것은 양쪽의 데이터 채널 설정이 제어하는 별도의 협상입니다, 그리고 tls-crypt로 보호된 터널도 의도하지 않은 암호를 사용할 수 있습니다.

마지막으로 공유 키 자체를 다루어야 합니다. 비밀로 취급하고, 승인된 경로로 배포하며, 그것을 가진 사람이 떠나면 교체하세요. 공유되기 때문에 그 노출은 그것을 사용하는 모든 끝점의 노출입니다.