TLS 고정과 VPN 입장은 서로 다른 질문에 답한다

사설 모바일 앱을 VPN 뒤에 두면 합리적인 사람은 그 앱에 아직 인증서 고정이 필요한지 묻습니다. 그 질문은 동등한 두 통제 중 하나를 고르는 것처럼 들리지만, 실제로는 서로 다른 두 관문에 대한 질문입니다. VPN은 이 기기가 그 경로를 쓸 수 있는지를 정하고, 앱은 도달한 서버가 기대한 서버인지를 정합니다. 둘을 따로 답하면 설계가 더 단순해집니다.

두 관문, 두 질문

네트워크 입장은 클라이언트의 문제입니다: 이 기기가 등록되었는지, 자격 증명이 유효한지, 정책이 이 경로로 들여보내는지. 앱의 신뢰는 서버의 문제입니다: 연결이 앱이 받아들이는 신원을 가진 서비스에 도달했는지. 이 답들은 서로 다른 시스템에서 오고, 다른 이유로 실패하며, 다른 팀이 고칩니다. VPN 핸드셰이크가 성공해도 앱은 상대 뒤의 만료된 인증서와 대화하고 있을 수 있습니다. 완벽하게 고정된 앱도 기기가 네트워크에 들어오지 못하면 아무도 닿을 수 없습니다.

둘은 더해집니다. 하나를 빼면 통제가 하나 줄고, 다른 하나를 더해도 그것을 대신하지 못합니다.

고정이 실제로 제한하는 것

고정은 앱이 받아들일 서버 신원의 집합을 좁히며, 보통은 저장소가 보증하는 모든 체인을 신뢰하는 대신 공개 키나 인증서 해시를 지정합니다. 이것은 일반 검증 위에 얹는 제약이며 그 대체가 아닙니다. 일반 검증은 체인이 애초에 신뢰할 만한지를 답하고, 고정은 그것이 이 앱이 기대하는 체인인지를 답합니다. 첫 단계를 건너뛰는 구현은 안전성을 얻은 것이 아니라 새로움만 얻은 것입니다.

고정하는 대상은 플랫폼마다 다르므로 그 단어만으로는 거의 알 수 없습니다. 한 제품의 신뢰 저장소에서 해시를 복사해 모바일 앱에서 같은 것으로 취급하는 것은 흔하고 조용한 실수입니다.

플랫폼에서의 고정은 구성이지 정책이 아닙니다

Android는 네트워크 보안 구성으로 고정을 노출하며, 핀 집합이 공개 키의 다이제스트를 담고 체인은 그중 최소 하나를 포함해야 합니다. 그 파일은 앱마다 따로 있으며 의도적인 빌드 변경이 필요합니다. iOS에는 이에 상응하는 매니페스트 방식이 없어서 고정은 앱 자체의 신뢰 평가 코드에 삽니다.

방식이 다르므로 요구 사항은 플랫폼마다 써야 합니다. 플랫폼을 밝히지 않고 인증서를 고정하라고 말하는 정책은 구현할 수 없습니다.

교체가 고정의 생존을 결정합니다

어려운 부분은 첫 릴리스가 아니라 그 뒤의 인증서 갱신입니다. 엄격한 신뢰 정책은 정당한 새 키도 공격자의 키만큼 단호하게 거부합니다.

교체를 견디게 하는 방식은 둘입니다: 필요해지기 전에 이미 신뢰하는 예비 핀, 그리고 핀 집합에 만료일을 두어 앱을 막아 세우는 대신 시행이 끝나게 하는 것입니다. 둘 다 정책 결정이며, 특히 만료는 무해한 타이머가 아니라 의도적인 안전성 저하입니다. 앱 빌드와 TLS 종단점, 인증서 갱신을 누가 통제하는지 이름을 붙이고 그것들을 하나의 변경 과정에 모으십시오. 그 셋이 서로 다른 팀이라면 고정은 결국 아무도 예정하지 않은 장애를 일으킵니다.

분실한 기기는 세 번째 문제입니다

VPN 자격 증명을 폐기한다고 앱 세션이 반드시 끝나지는 않으며, 서버 고정은 남의 손에 있는 전화기에 대해 아무것도 하지 않습니다. 기기 잠금, 자격 증명 저장, 세션 수명, 원격 폐기는 각기 다른 주인을 가진 별개의 결정입니다. 이것들을 고정 논의에 접어 넣으면 그중 어느 것도 설계되지 않는다는 것이 보장됩니다.

보이는 하나의 관계 대신 네 가지 관계를 시험하십시오: 의도한 서버와 동작, 거부되어야 할 계정, 거부되어야 할 서버 신원, 계획된 교체입니다. 작동하는 VPN은 첫 번째만 연습합니다. 각 시험이 무엇을 증명했는지 적어 두십시오, 다음 사람은 초록 터널이 네 가지 모두 통과했다는 뜻이라고 여길 테니까요.