최근 Firefox의 추가 기능 비활성화에 대한 기술적 세부 사항

메모 번역자: 독자의 편의를 위해 날짜는 모스크바 시간으로 제공됩니다.

최근 추가 기능에 서명하는 데 사용되는 인증서 중 하나가 만료되는 것을 놓쳤습니다. 이로 인해 사용자가 추가 기능을 사용할 수 없게 되었습니다. 이제 문제는 대부분 해결되었으니, 무슨 일이 일어났는지, 어떤 작업이 이루어졌는지 자세히 공유해드리고 싶습니다.

배경: 추가 및 서명

많은 사람들이 기본적으로 브라우저를 사용하지만 Firefox는 "추가 기능"이라는 확장 기능을 지원합니다. 도움을 받아 사용자는 브라우저에 다양한 기능을 추가합니다. 15개 이상의 추가 기능이 있습니다: 광고 차단 에 수백 개의 탭 관리.

설치된 추가 기능에는 다음이 있어야 합니다. 전자 서명, 악성 추가 기능으로부터 사용자를 보호하고 Mozilla 직원이 추가 기능을 최소한으로 검토하도록 요구합니다. 우리는 2015년에 이 요구 사항을 도입했습니다. 심각한 문제 악성 추가 기능이 포함되어 있습니다.

작동 방식: 모든 Firefox 사본에는 "루트 인증서"가 포함되어 있습니다. 이 "루트"의 키는 다음 위치에 저장됩니다. 하드웨어 보안 모듈(HSM)네트워크 액세스 없이. 몇 년마다 새로운 "중간 인증서"가 이 키로 서명되며, 이는 추가 기능에 서명할 때 사용됩니다. 개발자가 추가 기능을 제출하면 임시 "최종 인증서"가 생성되고 중간 인증서를 사용하여 서명됩니다. 그런 다음 추가 기능 자체가 최종 인증서로 서명됩니다. 개략적으로 그것은 이렇게 보인다.

각 인증서에는 "주체"(인증서가 발급된 대상)와 "발급자"(인증서를 발급한 사람)가 있다는 점에 유의하세요. 루트 인증서의 경우 "주체" = "발급자"이지만 다른 인증서의 경우 인증서 발급자는 서명된 상위 인증서의 주체입니다.

중요한 점: 각 추가 기능은 고유한 최종 인증서로 서명되지만 거의 항상 이러한 최종 인증서는 동일한 중간 인증서로 서명됩니다.

작성자 메모: 매우 오래된 추가 항목은 예외입니다. 당시에는 다양한 중간 인증서가 사용되었습니다.

이 중간 인증서로 인해 문제가 발생했습니다. 각 인증서는 특정 기간 동안 유효합니다. 이 기간 이전이나 이후에는 인증서가 유효하지 않으며 브라우저는 이 인증서로 서명된 추가 기능을 사용하지 않습니다. 아쉽게도 중간 인증서가 4월 4일 오전 XNUMX시에 만료되었습니다.

결과는 즉시 나타나지 않았습니다. Firefox는 설치된 추가 기능의 서명을 지속적으로 확인하지 않지만 대략 24시간마다 한 번씩 확인하며 확인 시간은 각 사용자마다 다릅니다. 그 결과, 어떤 사람들은 즉시 문제를 겪었고, 다른 사람들은 훨씬 나중에 문제를 겪었습니다. 우리는 인증서가 만료될 무렵에 처음으로 문제를 인지하고 즉시 해결책을 찾기 시작했습니다.

피해 감소

무슨 일이 일어났는지 알게 된 후, 우리는 상황이 더 악화되는 것을 막으려고 노력했습니다.

첫째, 그들은 새로운 추가 항목의 수락 및 서명을 중단했습니다. 이를 위해 만료된 인증서를 사용하는 것은 의미가 없습니다. 돌이켜보면 모든 것을 그대로 놔둘 수도 있었을 것 같아요. 이제 보충제 접수를 재개했습니다.

둘째, 매일 서명을 확인하지 못하게 하는 수정 사항을 즉시 보냈습니다. 따라서 우리는 지난 XNUMX시간 동안 브라우저에서 아직 추가 기능을 확인할 시간이 없었던 사용자를 저장했습니다. 이 수정 사항은 이제 철회되었으며 더 이상 필요하지 않습니다.

병렬 작동

이론적으로 문제에 대한 해결책은 간단해 보입니다. 유효한 새 중간 인증서를 만들고 각 추가 기능에 다시 서명하는 것입니다. 불행하게도 이것은 작동하지 않습니다:

• 한 번에 15개의 추가 기능을 신속하게 다시 서명할 수 없습니다. 시스템은 이러한 로드를 위해 설계되지 않았습니다.
• 추가 사항에 서명한 후에는 업데이트된 버전을 사용자에게 전달해야 합니다. 대부분의 추가 기능은 Mozilla 서버에서 설치되므로 Firefox는 다음 XNUMX시간 이내에 업데이트를 찾을 수 있지만 일부 개발자는 타사 채널을 통해 서명된 추가 기능을 배포하므로 사용자는 이러한 추가 기능을 수동으로 업데이트해야 합니다.

대신 우리는 모든 사용자가 별다른 조치를 취하지 않거나 전혀 조치를 취하지 않고도 모든 사용자에게 적용할 수 있는 수정 사항을 개발하려고 노력했습니다.

매우 빠르게 우리는 동시에 사용하는 두 가지 주요 전략에 도달했습니다.

• 인증서 유효 기간을 변경하려면 Firefox를 업데이트하세요. 이렇게 하면 기존 추가 기능이 마술처럼 다시 작동하게 되지만, 새로운 Firefox 빌드를 출시하고 출시해야 합니다.
• 유효한 인증서를 생성하고 만료된 기존 인증서 대신 Firefox가 인증서를 수락하도록 설득하세요.

우리는 꽤 실행 가능해 보이는 첫 번째 옵션을 먼저 사용하기로 결정했습니다. 결국 그들은 두 번째 수정 사항(새 인증서)을 출시했습니다. 이에 대해서는 나중에 설명하겠습니다.

인증서 교체

위에서 언급했듯이 다음이 필요했습니다.

• 새로운 유효한 인증서 생성
• Firefox에 원격으로 설치

이것이 작동하는 이유를 이해하기 위해 추가 기능 확인 프로세스를 자세히 살펴보겠습니다. 추가 기능 자체는 서명에 사용되는 인증서 체인을 포함하여 파일 세트로 제공됩니다. 결과적으로 브라우저가 빌드 시 Firefox에 내장된 루트 인증서를 알고 있으면 추가 기능을 확인할 수 있습니다. 그러나 이미 알고 있듯이 중간 인증서의 유효기간이 만료되어 애드온 검증이 불가능합니다.

Firefox가 추가 기능을 확인하려고 시도할 때 추가 기능 자체에 포함된 인증서를 사용하는 것으로 제한되지 않습니다. 대신 브라우저는 최종 인증서부터 시작하여 루트에 도달할 때까지 계속해서 유효한 인증서 체인을 생성하려고 시도합니다. 첫 번째 수준에서는 최종 인증서부터 시작한 다음 주체가 최종 인증서(즉, 중간 인증서)의 발급자인 인증서를 찾습니다. 일반적으로 이 중간 인증서는 추가 기능과 함께 제공되지만 브라우저 저장소의 모든 인증서도 이 중간 인증서 역할을 할 수 있습니다. 새로운 유효한 인증서를 인증서 저장소에 원격으로 추가할 수 있으면 Firefox는 이를 사용하려고 시도합니다. 새 인증서 설치 전후 상황.

새 인증서를 설치한 후 Firefox는 인증서 체인을 검증할 때 두 가지 옵션을 갖게 됩니다. 이전의 유효하지 않은 인증서(작동하지 않음) 또는 새로운 유효한 인증서(작동함)를 사용하는 것입니다. 새 인증서에는 이전 인증서와 동일한 주체 이름과 공개 키가 포함되어 있어야 최종 인증서의 서명이 유효합니다. Firefox는 작동하는 옵션을 찾을 때까지 두 옵션을 모두 시도할 만큼 똑똑하므로 추가 기능이 다시 테스트됩니다. 이는 TLS 인증서의 유효성을 검사하는 데 사용하는 논리와 동일합니다.

작성자 메모: WebPKI에 익숙한 독자라면 교차 인증서가 정확히 동일한 방식으로 작동한다는 점을 알게 될 것입니다.

이 수정 사항의 가장 큰 장점은 기존 추가 기능에 다시 서명할 필요가 없다는 것입니다. 브라우저가 새 인증서를 받으면 모든 추가 기능이 다시 작동합니다. 남은 과제는 새 인증서를 사용자에게 (자동 및 원격으로) 전달하고 Firefox가 비활성화된 추가 기능을 다시 확인하도록 하는 것입니다.

노르망디와 연구 시스템

아이러니하게도 이 문제는 "시스템"이라는 특수 추가 기능으로 해결됩니다. 연구를 수행하기 위해 우리는 연구를 사용자에게 전달하는 Normandy라는 시스템을 개발했습니다. 이러한 연구는 브라우저에서 자동으로 수행되며 Firefox의 내부 API에 대한 향상된 액세스를 제공합니다. 연구에서는 인증서 저장소에 새 인증서를 추가할 수 있습니다.

작성자 참고 사항: 특별한 권한이 있는 인증서를 추가하지 않습니다. 이는 루트 인증서로 서명되므로 Firefox는 이를 신뢰합니다. 브라우저에서 사용할 수 있는 인증서 풀에 간단히 추가하면 됩니다.

따라서 해결책은 연구를 만드는 것입니다.

• 사용자를 위해 생성한 새 인증서 설치
• 브라우저가 비활성화된 추가 기능을 다시 확인하여 다시 작동하도록 강제

"하지만 잠깐만요. 추가 기능이 작동하지 않습니다. 시스템 추가 기능을 어떻게 시작할 수 있나요?"라고 말합니다. 새로운 인증서로 서명하자!

다 합치면... 왜 이렇게 오래 걸리나요?

따라서 계획은 다음과 같습니다. 기존 인증서를 대체할 새 인증서를 발급하고 시스템 추가 기능을 생성하여 노르망디를 통해 사용자에게 설치합니다. 제가 말했듯이 문제는 4월 4일 00시에 시작되었고, 이미 같은 날 12시 44분에 9시간도 채 지나지 않아 우리는 수정 사항을 노르망디로 보냈습니다. 모든 사용자에게 도달하는 데 6~12시간이 더 걸렸습니다. 전혀 나쁘지는 않지만 트위터 사람들은 왜 우리가 더 빨리 행동할 수 없었는지 묻고 있습니다.

먼저 새로운 중간 인증서를 발급하는데 시간이 걸렸습니다. 위에서 언급했듯이 루트 인증서의 키는 하드웨어 보안 모듈에 오프라인으로 저장됩니다. 루트는 거의 사용되지 않고 안정적으로 보호되어야 하기 때문에 보안 관점에서는 좋지만 새 인증서에 긴급하게 서명해야 하는 경우에는 약간 불편합니다. 엔지니어 중 한 명이 HSM 저장 시설로 이동해야 했습니다. 그런 다음 올바른 인증서를 발급하려는 시도가 실패했으며 각 시도마다 테스트에 XNUMX~XNUMX시간이 소요되었습니다.

둘째, 시스템 애드온 개발에 시간이 걸렸습니다. 개념적으로는 매우 간단하지만, 간단한 프로그램이라도 주의가 필요합니다. 우리는 상황이 더 악화되지 않도록 하고 싶었습니다. 연구 결과는 사용자에게 전송되기 전에 테스트되어야 합니다. 또한 추가 기능에 서명해야 하는데 추가 기능 서명 시스템이 비활성화되어 해결 방법을 찾아야 했습니다.

마지막으로 연구 제출 준비가 완료된 후 배포에는 시간이 걸렸습니다. 브라우저는 6시간마다 Normandy 업데이트를 확인합니다. 모든 컴퓨터가 항상 켜져 있고 인터넷에 연결되어 있는 것은 아니므로 수정 사항이 사용자에게 전파되는 데는 시간이 걸립니다.

최종 단계

연구는 대부분의 사용자에 대한 문제를 해결해야 하지만 모든 사람이 이용할 수 있는 것은 아닙니다. 일부 사용자에게는 특별한 접근 방식이 필요합니다.

• 연구 또는 원격 측정을 비활성화한 사용자
• 연구가 전혀 지원되지 않는 Android 버전(Fennec) 사용자
• 원격 측정을 활성화할 수 없는 기업의 Firefox ESR 맞춤형 빌드 사용자
• MitM 프록시 뒤에 앉아 있는 사용자(우리의 추가 기능 설치 시스템은 해당 프록시와 작동하지 않는 키 고정을 사용하기 때문)
• 연구를 지원하지 않는 레거시 버전의 Firefox 사용자

후자의 사용자 범주에 대해서는 우리가 할 수 있는 일이 없습니다. 오래된 버전에는 패치가 적용되지 않은 심각한 취약점이 있기 때문에 새 버전의 Firefox로 업데이트해야 합니다. 일부 사람들은 오래된 추가 기능을 실행하기 위해 이전 버전의 Firefox를 사용하고 있지만, 이전 추가 기능 중 상당수는 이미 최신 버전의 브라우저로 이식되었습니다. 다른 사용자를 위해 새로운 인증서를 설치하는 패치를 개발했습니다. 버그픽스 릴리스로 릴리스되었습니다(번역자 주: Firefox 66.0.5), 그래서 사람들은 정기적인 업데이트 채널을 통해 그것을 얻을 것입니다. 아마도 이미 그것을 얻었을 것입니다. Firefox ESR의 사용자 정의 빌드를 사용하는 경우 관리자에게 문의하세요.

우리는 이것이 이상적이지 않다는 것을 이해합니다. 어떤 경우에는 사용자가 추가 기능 데이터(예: 추가 기능 데이터)를 잃어버렸습니다. 다중 계정 컨테이너).

이러한 부작용은 피할 수 없지만 단기적으로는 대부분의 사용자에게 가장 적합한 솔루션을 선택했다고 믿습니다. 장기적으로 우리는 더 발전된 다른 아키텍처 접근 방식을 모색할 것입니다.

레슨

첫째, 우리 팀은 문제가 발견된 후 12시간 이내에 수정 사항을 작성하고 배송하는 놀라운 작업을 수행했습니다. 집회에 참석한 사람으로서 나는 이 어려운 상황에서 사람들이 매우 열심히 일했고 낭비된 시간이 거의 없었다고 말할 수 있습니다.

분명히, 이런 일이 전혀 일어나지 말았어야 했습니다. 그러한 사고의 가능성을 줄이고 문제 해결을 더 쉽게 만들기 위해 프로세스를 조정하는 것은 분명히 가치 있는 일입니다.

다음 주에 우리는 공식적인 사후 분석과 우리가 하려고 하는 변경 사항 목록을 발표할 것입니다. 지금은 내 생각을 공유하겠습니다. 첫째, 잠재적 시한폭탄의 상태를 모니터링할 수 있는 더 나은 방법이 있어야 합니다. 우리는 그 중 하나가 갑자기 작동하는 상황에 처하지 않도록 해야 합니다. 우리는 아직 세부 사항을 검토 중이지만 최소한 그러한 모든 사항을 고려할 필요가 있습니다.

둘째, 다른 모든 것이 실패하는 경우에도, 특히 모든 것이 실패하는 경우에도 사용자에게 업데이트를 신속하게 제공할 수 있는 메커니즘이 필요합니다. "연구" 시스템을 사용할 수 있다는 점은 좋았지만, 이는 불완전한 도구이고 원치 않는 부작용이 있었습니다. 특히, 우리는 많은 사용자가 자동 ​​업데이트를 활성화했지만 연구에 참여하기를 원하지 않는다는 것을 알고 있습니다(저도 이를 꺼 놓았습니다!). 동시에 사용자에게 업데이트를 보낼 수 있는 방법이 필요하지만 내부 기술 구현이 무엇이든 사용자는 업데이트(핫픽스 포함)를 구독할 수 있지만 다른 모든 항목은 거부할 수 있어야 합니다. 또한 업데이트 채널은 현재보다 응답성이 더 높아야 합니다. 6월 XNUMX일에도 여전히 수정본이나 새 버전을 활용하지 못한 사용자가 있었습니다. 이 문제는 이미 해결되었지만 발생한 사건은 그것이 얼마나 중요한지 보여주었습니다.

마지막으로 추가 기능의 보안 아키텍처를 자세히 살펴보고 손상 위험을 최소화하면서 적절한 수준의 보안을 제공하는지 확인하겠습니다.

다음 주에 무슨 일이 일어났는지에 대한 보다 철저한 분석 결과를 살펴보겠습니다. 그 동안에는 이메일로 질문에 기꺼이 답변해 드리겠습니다. [이메일 보호]

출처 : linux.org.ru