HTTPS를 통한 인증으로 인해 응용 프로그램이 느려 집니까?

웹 응용 프로그램 및 RESTful 웹 서비스를 구축 중입니다.

웹 서비스에 대한 요청을 인증하는 가장 좋은 방법에 대한 다양한 기사를 읽었습니다.

나에게 가장 좋은 옵션은 HTTP 기본 인증을 사용하는 것 같습니다. 거의 모든 기사에 따르면 인증은 SSL 또는 이와 동등한 것으로 암호화되어야한다고 말합니다.

이것이 무엇을 포함하는지 완전히 확신하지 못합니다. 이것은 전체 웹 서비스가 안전한 서버에 있어야한다는 것을 의미합니까? 이로 인해 속도가 느려 집니까?

우선, SSL (HTTPS) 및 HTTP 인증 작동 방식을 이해하십시오.

일반적인 HTTP 인증 방법 (다이제스트, 기본 및 HTTP를 기반으로 구현할 수있는 모든 양식 + 쿠키 기반 인증 체계)은 인증 정보를 일반 텍스트로 다소 전송하므로 자체적으로 안전하지 않습니다. 데이터가 POST 필드 또는 헤더에 있는지, base64 인코딩이 적용되는지 여부에 관계없이 네트워크 트래픽에 액세스 할 수있는 모든 사람이 비밀번호를 명확하게 볼 수 있습니다. 이는 신뢰할 수없는 채널을 통한 HTTP 인증이 가치가 없다는 것을 의미합니다. 공격자가 암호를 읽는 데 필요한 것은 네트워크 스니핑입니다.

SSL 은 본질적으로 안전하지 않은 채널을 통해 보안 통신 채널을 구현합니다. 이것은 대략 다음과 같이 작동합니다.

1. 서버가 서명 된 인증서를 보냅니다.
2. 클라이언트는 잘 알려진 서명 키 목록에 대해 인증서의 유효성을 검사합니다. 인증서 서명을 체인으로 연결할 수 있으므로 각 노드에 "서명하는 서명이 좋으면 나도 그래요"라고 말하지만 궁극적으로 체인은 클라이언트에 사전 구성된 소수의 신뢰할 수있는 기관 중 하나로 해결해야합니다.
3. 클라이언트는 서버의 공개 암호화 키를 사용하여 공유 비밀을 보냅니다.
4. 서버는 개인 키를 사용하여 공유 암호를 해독합니다 (합법적 인 서버에만 개인 키가 있으므로 다른 서버는 공유 암호를 해독 할 수 없습니다)
5. 클라이언트는 공유 비밀을 사용하여 암호화 된 실제 요청 데이터를 보냅니다.
6. 서버가 요청 데이터를 해독 한 다음 암호화 된 응답을 보냅니다.
7. 클라이언트는 응답을 해독하여 사용자에게 제공합니다.

여기에 몇 가지 중요한 사항이 있습니다.

• 인증서 체인을 사용하면 클라이언트가 대화하는 서버가 요청을 가로채는 사람이 아니라 실제 서버인지 확인할 수 있습니다. 이것이 바로 실제 SSL 인증서를 구입해야하는 이유이며 유효하지 않거나 만료되었거나 잘못된 인증서를 사용하는 사이트를 방문했을 때 브라우저가 무서운 경고를 표시하는 이유는 전 세계의 모든 암호화가 도움이되지 않는 것입니다 잘못된 사람과 이야기하는 것.
• 비밀을 교환하는 데 사용되는 공개 / 개인 암호화는 성공적인 통신이이 특정 클라이언트와 서버 사이에서만 작동하도록합니다. 스니핑 된 네트워크 패킷은 암호화되며 서버의 개인 키가 데이터를 가져 오도록 요구합니다.
• 대칭 암호화는 개인 / 공개 키 암호화보다 성능 오버 헤드가 훨씬 낮기 때문에 대량의 요청에 사용됩니다. 그러나 키 (공유 비밀)는 개인 / 공개 키 암호화를 사용하여 교환됩니다. 택배 서비스와 같은 별도의 채널을 통해 키를 전송하는 것을 제외하고는 안전한 방법으로 만 수행 할 수 있기 때문입니다.

따라서 분명히 약간의 오버 헤드가 수반되지만 생각보다 나쁘지는 않습니다. 절대적으로 방대한 양의 트래픽을 준비하지 않는 한 "더 많은 하드웨어를 던질 것"이 적절한 응답 인 규모입니다 ( 구글이나 페이스 북을 생각하십시오). 일반적인 상황, 즉 일반적인 웹 응용 프로그램 사용에서 SSL 오버 헤드는 무시할 수 있으므로 기밀 데이터를 가져 오면 리소스를 포함하여 SSL을 통해 모든 것을 실행하는 것이 가장 좋습니다. SSL은 HTTP 트래픽을 보호 할 수있는 유일한 방법이기도합니다. 다른 방법은 단순히 표준화되지 않았기 때문에 널리 지원되지 않으며, 솔직히 말해서 잘못하기가 너무 쉽기 때문에 이러한 것을 직접 구현하고 싶지 않습니다.

TL : DR : 예, SSL + 기본 인증은 좋은 생각입니다. 예, 보안 서버 (및 유효한 인증서 ) 가 필요합니다 . 그렇습니다. 일이 조금 느려질 것입니다. 아니요. 올바른 걱정은 아닙니다. 지금.

HTTPS (SSL)는 사용자 인증 FYI가 아닙니다. 두 엔드 포인트 사이의 암호화 만 제공합니다.

그러나 그렇습니다. 계획 / 하드웨어의 변경을 보증하기에 충분하지는 않지만 약간의 오버 헤드가 있습니다. 여기를 봐 :

/programming/548029/how-much-overhead-does-ssl-impose

HTTP 기본 인증을 사용하면 사용자가 제공 한 사용자 이름과 비밀번호가 모든 요청과 함께 서버로 전송됩니다. 즉, 사이트의 보안 영역에서 반드시 안전 할 필요는없는 일반 텍스트로되어 있습니다. 분명히, 사용자를 안전하게 지키기 위해 SSL을 원할 것입니다.

이론적으로 쿠키 인증을 사용하고 로그인 페이지 (사용자 이름과 비밀번호가 전송되는)에만 SSL을 사용할 수 있습니다. 쿠키가 재생 공격에 대해 안전하고 안전하다면 공격자는 쿠키를 얻었더라도 쿠키로 아무것도 할 수 없습니다.

기본 인증은 http 요청 헤더에 사용자 이름과 비밀번호를 설정하는 것입니다. SSL 또는 이와 동등한 것을 사용하지 않으면 해당 사용자 이름과 비밀번호가 일반 텍스트로 전송되며 누구나 훔치기가 쉽지 않습니다.

오늘날 대부분의 웹 서버는 기본적으로 HTTPS를 지원하며 모든 호출에 오버 헤드를 최소화하지만 오버 헤드는 최소입니다.

다른 엔드 포인트가 아닌 일부 엔드 포인트를 보호 할 수 있습니다 (예 : 다른 호출에 사용할 수있는 토큰을 생성하는 인증 엔드 포인트가 있음). 훨씬 더 안전하지만 전체 서비스에 SSL을 강력히 권장합니다. (다른 정보가 없으면 민감한 데이터를 가로 챌 수 없습니다)

Jeff Atwood는 얼마 전 완전한 암호화가 필요한지에 대한 간단한 블로그 게시물을 작성했습니다 . 그는 실제 사례를 설명하고 성능 고려 사항에 대해서도 몇 가지 설명을합니다.

또한 Gmail 사례 연구에 대한 이 기사를 인용하여 다음을 인용합니다.

올해 (2010 년 1 월) Gmail은 기본적으로 모든 것에 HTTPS를 사용하도록 전환했습니다. 이전에는 옵션으로 소개되었지만 이제는 모든 사용자가 HTTPS를 사용하여 브라우저와 Google간에 항상 이메일을 보호합니다. 이를 위해 우리는 추가 기계와 특별한 하드웨어를 배치하지 않아도되었습니다. 프로덕션 프론트 엔드 시스템에서 SSL / TLS는 CPU로드의 1 % 미만, 연결 당 10KB 미만의 메모리 및 네트워크 오버 헤드의 2 % 미만을 차지합니다. 많은 사람들이 SSL에 많은 CPU 시간이 필요하다고 생각하며 위의 숫자 (처음으로 공개)가이를 없애는 데 도움이되기를 바랍니다.

또한 브라우저 에서 HTTPS를 통해 페이지의 클라이언트 측 캐싱에 대한 개선점을 언급했습니다 .

그럼에도 불구하고, 그는 다른 처벌이 있으며, 대부분은 성능이 아니라 구현 비용이라는 점을 지적합니다.

• 이미 바쁜 팀을 위해 복잡성을 추가하면서 소프트웨어 품질을 유지
• 프록시 캐싱은 구성하기가 훨씬 어렵고 코드 변경도 필요합니다.
• 다양한 소스의 콘텐츠 매시업에 대한 보안을 확보하기가 어렵습니다.
• 저가형 휴대 기기는 암호화로 어려움을 겪을 수 있습니다.

자체 세션 처리가없는 HTTP 기본 인증은 교차 사이트 요청 위조 공격에 노출 될 수 있습니다. 자체 세션 처리와 함께 사용하는 경우이 기능을 사용할 수 있지만 "로그 아웃"기능을 제공하는 데 문제가있을 수 있습니다.

인증을 위해 무엇을 사용하든 상관없이 웹 응용 프로그램이 제어 된 보안 네트워크에서만 액세스되지 않는 한 HTTPS를 사용하여 연결을 암호화해야합니다 . 속도가 느려질 수 있습니다 (연결 설정은 비싸지 만 브라우저는 잠시 동안 연결을 유지하는 경향이 있습니다) . 안전한 응용 프로그램을 원한다면 어쨌든 피할 수 없으므로 실제로는 필요하지 않습니다. 그것에 대해 걱정하십시오.

참고 : "HTTPS 인증"(제목에서 언급 한)은 오해의 소지가 있습니다. SSL 클라이언트 인증서 인증을 의미 할 수 있습니다. SSL 클라이언트 인증서 인증은 질문 텍스트와 거의 관련이 없으며 자체 장점과 문제점이 있습니다. 당신은 아마 그것을 만지고 싶지 않습니다.

기본 인증을 어떻게 달성 하시겠습니까?
하드 코딩 된 사용자 이름 / 비밀번호이고 웹 서버의 내장 기능을 사용하면 거의 영향을 미치지 않을 것입니다. 데이터베이스 나 그와 비슷한 일에서 미쳤던 일을하고 있다면 영향을 미칠 수 있습니다.

다른 사람들이 여기에서 언급했듯이 SSL 및 추가 헤더를 보내면 기술적으로 속도가 느려지지 만 아무런 의미가 없습니다.