it-swarm-korea.com

클라이언트 브라우저 인증서를 사용하는 사람이 있습니까?

클라이언트 브라우저 인증서는 침입자로부터 사이트를 보호하는 좋은 방법 인 것 같습니다. 추측하기가 어렵고 훔치기가 더 어려워 야합니다. 물론 모든 문제를 해결하지는 않지만 보안을 추가합니다.

그러나 공개 사이트를 사용하지 않았습니다. 그것들을 사용하는 사이트가 있습니까? 보안이 중요한 경우에도 사용을 방해하는 결함이 있거나 사용이 적은 다른 이유가 있습니까?

43
StasM

인증 된 고객 측은 충분한 비용/혜택 트레이드 오프를 얻지 못했습니다. 이들은 사용자에게 매우 혼란 스럽기 때문에 지원 비용이 상승합니다. 그리고 그들은 여전히 ​​약간의 비트이므로 "알고있는 것"이며 브라우저, 배포 체계, 피싱 등에 대한 다양한 소프트웨어 공격에 취약합니다.

하드웨어 토큰 체계 (이중 인증)는 인증에 더 좋습니다. 잠재적으로 연합되고 잠재적으로 하드웨어 토큰으로 지원되는 싱글 사인온 (SSO) 체계는 더 많은 문제를 해결하고 배치하기가 더 쉽습니다.

많은 인증서 관리는 현재의 복잡한 다중 암호 문제보다 사용자에게 훨씬 더 복잡 할 수 있으며 브라우저는 올바른 인증서를 선택하기위한 적절한 지원을 제공하지 않습니다. 사용자가 많은 사이트에 단일 인증서를 사용하는 경우 인증서를 사용하면 사용자를 식별하므로 개인 정보 보호 문제가 있습니다.

수십 년 동안, 우리 중 많은 사람들이 최종 사용자 PK- 암호화 시대는 특히 RSA의 아름다움에 매혹 된 사람들과 매우 유사하다고 생각했습니다. 단지 진화 한 방식, 헬프 데스크 및 개발 비용, 미묘함, 복잡성 및 실제 PKI의 법적 얽힘이 계속해서 혜택을 누리고 있음이 밝혀졌습니다.

장비는 비트보다 비싸 보이지만 비트가 작업을 수행하지 않거나 효과적으로 사용하면 생산성이 떨어집니다.

20
nealmcb

소수의 사이트에는 브라우저 인증서를 사용하지만 대부분 not 공개 사이트라고 말한 것처럼.

클라이언트 측 인증서의 주요 어려움은 배포입니다. 즉, 내가 모르는 경우 시스템에 대한 액세스 권한을 부여하는 "강력한"인증서를 어떻게 안전하게 제공 할 수 있습니까?
물론 소규모 시스템 파트너에게 개방 된 시스템과 마찬가지로 기업 시스템은 더 쉽습니다. 그러나 키 분배는 항상 해결하기 어려운 퍼즐입니다. 개인 키 측면과 인증서 보호를 고려하여 두 당사자간에 암호를 공유하는 것보다 훨씬 어렵습니다 ....

물론 이것에 대한 are 솔루션이 있으며, "공개"웹 사이트를위한 솔루션도 사용합니다. (아이덴티티 사업에 있기 때문에 그들에게 오버 헤드 가치가 있습니다 ...). 이 솔루션은 비밀번호를 통한 기본 인증을 기반으로하며, 완전히 인증 된 후 인증서를 다운로드 할 수있는 옵션이 있습니다.
비밀번호 채널이 아직 열려 있기 때문에 많이 더 좋지 않습니다. 그러나 적어도 암호를 불가능하고 사용할 수없는 것으로 변경할 수 있으며 CSC 만 있습니다. ...

그러나 이것은 사소한 것이 아니며 올바르게 구현하기가 다소 복잡합니다. 배포는 여전히 대부분의 사용자에게 버그가 있습니다.

18
AviD

내가 이해하는 것처럼 실제로 클라이언트 인증서를 사용하는 데는 많은 문제가 있습니다. 내가 들었던 문제 중 일부는 다음과 같습니다.

  1. 클라이언트 인증서 받기 사용자가 처음에 클라이언트 인증서를 처음 얻는 것은 고통입니다. 분명히, 사이트는 사용자가 사이트를 사용하기 전에 뛰어 넘어야하는 불필요한 장애물을 만들고 싶지 않습니다. (사이트가 클라이언트 인증서를 생성하여 클라이언트에게 제공하는 것조차도 사용자에게는 친숙한 작업이 아닙니다. 이상적으로는 클라이언트 만이 클라이언트의 개인 키를 알아야하기 때문에 보안 문제가 있다는 것은 말할 것도 없습니다.) 최신 브라우저 개인 키와 클라이언트 인증서를 만들거나 가져 오는 방법을 제공하지만 사용자 경험은 끔찍합니다.

  2. 일부 서버는 분명히 클라이언트 인증서를 잘 지원하지 않는다고 들었습니다 (예 : http://osdir.com/ml/encryption.cryptlib/2005-09/msg00000.html).

  3. 이동성은 문제입니다. 모든 문제에도 불구하고 암호는 이식성이 뛰어납니다. 클라이언트 인증서는 없습니다. 클라이언트가 개인 키를 생성하고 클라이언트 인증서를 발급 받더라도 두 번째 컴퓨터를 사용하려면 개인 키와 인증서를 두 번째 컴퓨터로 옮기려면 복잡하고 혼란스러운 춤을 추어 야합니다. 컴퓨터. 첫 번째 컴퓨터가 죽거나 하드 디스크 오류가 발생하여 OS를 다시 설치하거나 새 컴퓨터를 구입해야하는 경우 클라이언트가 개인 키를 백업하지 않으면 개인 키를 넣을 방법이 없습니다 새 컴퓨터의 키와 인증서 그들은 꽤 망했다. 사이트는 개인 키를 잃어버린 사용자가 새로운 개인 키를 생성하고 제출할 수 있도록 백업의 백업 방법을 만들 수 있지만이 백업 방법은 체인에서 가장 취약한 링크가 될 수 있습니다. 백업 방법이 쉽게 무력화되는 경우 기본 인증 방법이 아무리 강해도 중요하지 않습니다.

  4. 클라이언트 인증서에 대한 브라우저의 충분한 지원이 있는지 확실하지 않습니다. 모바일 브라우저를 포함한 다양한 브라우저가 클라이언트 인증서를 적절히 지원하는지 여부는 알 수 없습니다.

  5. 어쨌든 PKI 모델은 잘 깨졌습니다. CA는 클라이언트 인증서를 제공하기 전에 사용자의 신원 (예 : 실명)을 확인하고이 가정을 중심으로 프로토콜을 설계했다고 가정했습니다. 그러나 오늘날의 CA는 실제로 신원을 확인하지 않습니다. 이것은 설계 가정과 현실 사이에 불일치를 만듭니다.

  6. 클라이언트 인증서는 사용자를 위해 개인 정보 위험 을 만듭니다. 일부 브라우저에서는 여러 도메인에서 사용자를 추적 할 수 있습니다. (모든 브라우저는 쿠키가이 위협에 대해 신중하게 방어하도록합니다. 쿠키를 설정 한 도메인 만 읽을 수 있습니다. 그러나 브라우저는 SSL 클라이언트 인증서에 대해 유사한 보호 기능을 통합하지 않습니다.) 최신 브라우저가이 문제를 효과적으로 해결했는지는 알 수 없습니다. 문제이지만, 내가 아는 한, 클라이언트 인증서가 상대적으로 미숙 한 영역입니다.

  7. 클라이언트가 자체 클라이언트 인증서를 생성하고 서명하면 성가신 기술적 인 문제가 있습니다. TLS 프로토콜에 따르면 서버는 먼저 수락 할 CA 목록을 요청해야합니다. 클라이언트는 해당 CA에서 발급 한 클라이언트 인증서 (있는 경우)로 응답합니다. (클라이언트가 HTTP 요청, HTTP 쿠키, 사용자 이름 또는 기타 식별 정보를 보내기 전에 발생합니다.) 이는 클라이언트에서 발행 한 (자체 서명 된) 클라이언트 인증서를 사용하려는 경우 서버는 클라이언트가 자신을 인증하거나 식별하기 전에 클라이언트가 사용하고있는 CA의 이름을 알아야합니다. 까다 롭습니다.

  8. 마지막으로, 파이의 체리 : 클라이언트 인증서는 피싱 문제를 해결하지 못합니다. 클라이언트의 개인 키 도용을 방지하지만 다른 개인 정보는 도용하지 않습니다. 악의적 인 사용자는 여전히 가짜 은행 사이트를 설정할 수 있습니다 (여기서 보낸 클라이언트 인증서는 버림). 피싱 사이트는 사용자의 개인 키를 배우지 않지만 사용자가 실제 은행 사이트에 연결되었다고 생각하면 은행 계좌 번호, SSN, PIN 등을 입력하여 해당 정보를 공격자에게 공개 할 수 있습니다.

이러한 모든 기능은 유용성이 떨어지고 지원 비용이 증가합니다 (예 : 헬프 데스크 전화). 요컨대, 최소한 원칙적으로 can 클라이언트 인증서를 사용합니다. 실제로는 그렇게하는 것이 모든 사람에게 불편하고 유용성이 떨어진다는 것입니다.

더 근본적으로, 닭과 계란 문제가 있습니다. 많은 사이트에서 클라이언트 인증서를 사용하기 시작할 때까지 브라우저 제조업체는 클라이언트 인증서를 사용할 수 있도록 우선 순위를 두지 않습니다. 브라우저가 클라이언트 인증서를 사용 가능하게 만들 때까지 사이트는이를 채택하지 않습니다. 다시 말해 클라이언트 인증을 사용하여 일반 인증 문제를 해결하려면 모든 브라우저 제조업체가 브라우저를 크게 변경하도록 both 설득해야합니다. and 설득 사이트 새로운 기술을 채택합니다. 이러한 모든 당사자가 조정 된 변경을 수행 할 때까지 누구에게도 혜택이 발생하지 않습니다. 그것은 입양에 큰 장애물입니다.

HTTPS, 보안 영구 쿠키 및 이메일 기반 복구를 포함하여 웹에서 보안 인증을위한 더 나은 솔루션이 있습니다. 그러나 그것은 당신의 질문의 범위를 벗어나고 있습니다.

마지막 의견 : 안전한 웹 인증의 기본 과제는 유용성, 유용성, 유용성입니다. 일반 사용자가 시스템을 사용할 가능성이 높을 때 사용자에게 적합하고 안전한 시스템을 만드는 것은 매우 어려운 일이며 모든 것이 중요합니다. 암호화는이 문제의 작은 부분 일뿐입니다.

15
D.W.

나는 보통 사람들 (즉,이 질문을하기 때문에 당신이 아닌)이 사용법을 추측 할 수 없기 때문에 주로 사용되지 않는다고 생각합니다. 이 사이트를 사용하는 몇 개의 상업용 사이트가 있지만 일반적으로 매우 특별한 목적이나 자동화를위한 것입니다. 예를 들어, Oracle은 클라이언트 인증서를 사용하여 패키지 업데이트에 대한 유효한 지원 계약으로 최종 사용자를 검증합니다. 그러나 고도의 기술 사용자라도 적절한 키 교환을 얻는 것은 어려울 수 있습니다.

그 말은 모두 클라이언트 인증서를 사용하여 공개 된 웹 사이트의 일부를 보호하며 환상적이라고 생각합니다.

7
bahamat

Estonian National Identity Card 는 클라이언트 인증서가 포함 된 스마트 카드입니다. 스마트 카드 리더기를 구입하여 집에서 사용하여 정부 서비스를 신청하거나 주요 에스토니아 은행에 인증 할 수 있습니다. 모든 사용자에게 보이는 것은 카드/핀 프롬프트이며 다음에 인증 된 것으로 알고 있습니다.

6
blowdart

고객 중 클라이언트 인증서를 사용하여 터치 스크린 키오스크 시스템을 인증합니다. 이 시스템은 딜러에게 배포되며 각각은 고유 한 클라이언트 인증서뿐만 아니라 CA 루트 인증서도 설치합니다.

클라이언트 인증서는 딜러가 장치 시작시 수동 인증을 수행 할 필요없이 키오스크 시스템을 웹 서버에 인증하는 데 사용됩니다. 개별 시스템을 종료해야하는 경우 고객이 인증서를 쉽게 취소 할 수 있습니다.

5
Martijn Heemels

프랑스 경제부 장관은 사용자 인증을 위해 SSL 인증서를 사용하는 세금 관리 (온라인 세금 납부, 마감일 정보, 양식 다운로드 ...)를위한 공개 웹 사이트를 게시했습니다. 사용자 등록 (이 역할은 PKI의 Registration Authority에 귀속됨) AviD ♦에서 해당 프로젝트의 주요 난제로 지적한 바 있습니다. 납세자를 식별하십시오.

4
Jcs

다양한 브라우저 인증서가 HTTP/S 기반 ActiveSync 프로토콜에서 사용됩니다.

일부 전자 메일 관리자는 인증서를 사용하여 모바일 장치를 인증하므로 사용자가 암호를 변경할 때 모바일 전자 메일이 갑자기 작동을 멈추지 않습니다.

1
goodguys_activate

클라이언트 인증서는 인증에있어 가장 좋은 품질을 제공합니다. 그러나 닭고기 및 계란 문제로 인해 사용자는 심각한 인증서를 얻을 이유가 없습니다 (배달은 대면 작업이어야하기 때문에 돈과 시간이 소요됩니다). 사용자에게는 일반적으로 인증서가 없습니다.

보안 요구 사항이 충분히 높으면 PKI 인프라의 글로벌 비용이 완벽하게 예상되므로 회사 시스템이 다릅니다.

그러나 국가 신분증 (여권을 말하지 않고)의 실제 총 비용과 절차가 무엇인지 기억할 때, 국가 관리 기관에서 설정 한 인증서를 추가해도 많은 것이 추가되지 않으며 관리 기관과 같은 기관 사이트의 모든 인증 질문을 멋지게 해결할 수 있습니다. 은행, ... 물론 가맹점 사이트 나 통제 된 포럼에는 사용하지 않을 것입니다

1
Serge Ballesta

스마트 카드 인증을 제공하는 사이트를 개발 중입니다. 사용자는 USB 카드 리더기를 연결하고 사이트로 이동 한 후 로그인을 원할 때 카드를 삽입하고 PIN을 제공합니다. 문제는 시스템에서 Java 애플릿을 사용하며 이러한 애플릿은 더 이상 Chrome 또는 MS Edge에서 지원되지 않음) 새로운 미들웨어가 개발되고 있다는 것입니다. Java 애플릿을 사용하지 마십시오. 앞으로 모든 주요 브라우저가 Java 애플릿이 PC의 하드웨어와 상호 작용하는 것을 막을 수 있음)를 볼 수 있기 때문에 시간에 대한 경쟁입니다.

0
Totoro53

OP 범위를 확장하면 브라우저를지나갑니다. 브라우저 이외의 컨텍스트에서도 클라이언트 인증서를 사용할 수 있습니다. 예를 들어 Docker는 TLS와 클라이언트 인증서를 사용하여 원격 도커 클라이언트와 데몬 간의 연결을 보호합니다.

그래도 관리해야하지만 본격적인 CA를 통과 할 필요는 없으며 내부 회사 CA가 시스템에서 사용하는 모든 인증서를 관리 할 수 ​​있습니다.

0
Archimedes Trajano