내장 된 HTTPS 서버. 리디렉션을 어떻게 처리해야하며 HTTP를 제공해야합니까?

Question

I는 장치의 보안 원격 구성 목적을위한 하드웨어의 조각 내부에 앉는 HTTPS 서버를 구현

배경. 이를 위해 필자는 기존의 경량 임베디드 TCP/IP 스택을 오픈 소스 SSL 라이브러리와 함께 사용했습니다. 그 위에 앉아있는 웹 서버는 완전히 처음부터 작성되었습니다. (이것은 휠을 재창조하는 것처럼 보일 수 있지만, 우리의 목적을 위해 매우 가볍고 매우 좁은 특정 기능 세트가 필요합니다. 예를 들어, 우리가 사용하는 임베디드 RTOS와의 호환성 및 ROM "파일 시스템". 이 시스템은 HTTP (S) 세션 및 SSL 컨텍스트에 대해 수백 메가 바이트가 아니라 수백 킬로바이트 만 사용할 수있는 시스템입니다. 모든 것을 고려하고 다양한 다른 제품을 검토 한 후에 내 제품을 만드는 것이 합리적입니다. 이 웹 서버는 5 ~ 10 개의 동시 소켓 연결 (즉, 5 ~ 10 개의 동시 또는 영구 HTTP 연결)을 지원하기 만하면됩니다. 이는 하드웨어만큼 처리 할 수 ​​있습니다. 상자를 관리하기 위해 한 두 사람 만 액세스 할 수 있도록 설계되었으므로 괜찮습니다.

현재 모두 훌륭한 작품입니다. HTTP 1.1에 필요한만큼 RFC2616을 구현하도록 코딩했습니다. 지금이 순간, 그것은 불과 5 개 HTTPS 포트 (443)에서 수신 대기하고 아직 포트에서 리디렉션 아무것도 구현하지 않은 80 ​​

첫 번째 질문 - 재 난에서 리디렉션에 대한 수많은 기사를 보았다

HTTP에서 HTTPS로, 그러나 내가 읽은 모든 것은 이것을하기 위해 기존의 웹 서버와 기존의 웹 서버를 구성하는 방법에 관한 것이다. 프로그래밍 방식으로 구현해야하므로 프로토콜 수준에서 사용되는 기술이 무엇인지 알아야합니다.

일반적인 방법은 301/302 응답을 보내는 것입니다. 그래서, 내가 뭘 생각했던 전략은 내가 팔 동시 요청에 대한 자원을 가지고 예를 위해 가정이다

• 는 HTTPS 연결에 포트 443에 들어요. 최대 6 개의 동시 HTTPS 연결 (6 개 소켓)을 사용할 수 있습니다.

• HTTP 연결 및 최대 두 개의 HTTP 연결 (따라서 포트 80에 두 개의 소켓)을 사용할 수 있습니다. 포트 80의 소켓에서는 실제 웹 서버에 실제로 액세스 할 수 없습니다. 대신, 소켓에서 \r\n\r\n 또는 \n\n (요청 헤더의 끝을 알 수 있음)이 표시 될 때까지 계속 읽은 다음 301 (또는 302) 응답을 반환합니다.이 코드는 내 코드에서 하드 코드 된 const char* 문자열 일 것입니다. 그런 다음 소켓을 닫습니다. 이 두 포트 80 소켓은 리디렉션 목적으로 만 존재합니다.

이 전략이 현명한 것으로 들리는가요?

현재로서는 잘 모르겠지만 301/302 응답에 리디렉션 URL이 포함되어 있습니다. 이 하드웨어 '박스'는 집이나 라우터 뒤에서 어쩌면 동적 DNS 서비스 등을 통해 액세스 할 수있는 장치입니다. 따라서 프로그래밍 방식으로 동등한 HTTPS URL을 어떻게 결정합니까? 아마도 요청 URI에있는 내용과 원본 HTTP 요청 헤더의 host: 필드를 조합하여 사용하고 있을까요?

위의 사항이 문제가된다면 다음으로 가장 좋은 아이디어는 브라우저에서 URL을 가져 와서 HTTPS 리디렉션을 수행하는 자바 스크립트가 포함 된 작은 HTML 조각을 다시 게재하는 것입니다. 자바 스크립트 메소드 나는 이것을하기 위해 호출 할 것이지만, 나는 기억할 수 없다. (현재 SSL 인증서가 지정 될 수있는 특정 도메인이 없다는 것을 고려해 볼 때 SSL 인증서가 어떻게 작동할지는 확신 할 수 없지만 나중에 별도의 SO 질문에서 해당 브리지를 교차 할 것입니다.)

두 번째 질문 - HTTP 및 HTTPS 제공

이것은 프로그래밍 질문보다 디자인 문제가 많을 수도 있고 고객이 원하는 것보다 더 많이 생각할 수도 있습니다.하지만 어쨌든 여기에있는 코드를 볼 수있을 것이라고 생각했습니다. 사람들이 가진 의견. 내 문제는 클라이언트가 단순히 상자에 "SSL이 있어야한다고"명시했지만 그 이상은 아닙니다. 내가 모르는 것은 그들이 예를 들어 SSL 사용 여부에 대해 최종 사용자에게 선택권을 제공 할 수있을 것으로 기대하는 것입니다. 실제로 그들에게 물어보기 전에, 나는 단지 이 일지를 예상하고 있습니다. 저는 미리 지식과 대답을 가지고 스스로를 무장시키고 싶습니다. 다른 말로하자면, "자물쇠를보고 싶다"와 "SSL을 원한다"라는 명세를 작성하는 사람들은 분명히 이 좋은 것입니다. 것; 그러나 나 자신을 속여서 제안해야합니다.

우선 SSL을 사용하는 중간 방식 솔루션과 같은 것이 없다는 것을 알고 있습니다. 다시 말해, HTTPS를 통해 중요한 정보를 제공함으로써 수행해야하는 작은 작업을 줄이기 위해 노력했지만 HTTP를 통해 이미지와 CSS 파일을 제공한다고 가정 해 보겠습니다. 몇 가지 독서를 한 후에 나는 이것이 왜 여러 이유에서 절대적으로 아니오인지 정확하게 알고 있습니다.

그러나 내가 한 경우 최종 사용자가 일부 초기 로그인 페이지에서 HTTPS 또는 HTTP를 선택할 수있는 기능을 제공합니까? 'HTTPS'를 선택하면 보안 HTTPS 로그인 페이지로 리디렉션됩니다. 예를 들어 휴대 전화에서 상자에 액세스 할 때 추가 액세스 속도를 위해 사용자가 보안을 침해하도록 선택해야하는 경우 유용한 옵션 일 수 있습니다. 이 초기 페이지는 '보안 로그인'과 '표준 보안되지 않은 로그인 - 권장되지 않음'또는 유사 할 수 있습니다. 분명히 이것은 사용자가 염려하는 한 취약점을 열어 주지만 SSL 연결을 손상시킬 수 있습니까? 이것이 의미하는 바는 HTTP를 통해 초기 로그인 페이지가 제공되어야하기 때문에 이론상 공격자가 버튼을 바꿔 놓을 수 있다는 것입니다. 따라서 HTTPS가 처음부터 HTTPS 을 의미하면일까요? 이 문제에 HTTPS를 사용하여 HTTPS를 작동시키고 작동하도록 만들었고 또한 현대적인 브라우저 (IE8/9, FF)와 함께 사용하도록 특별히 설계된 것을 감안할 때 일반적인 HTTP 액세스가 있어야하는 실질적인 이유가 있습니까? 대안으로 제안 되었습니까?

Answer 1

질문 1 : 두 기술 모두 사운드가 상용 사이트에서 정기적으로 사용되는 것으로 생각되지만 호스트 헤더를 읽고 301을 반환하는 것은 공간이 서버 끝에서 실제로 너무 제한적이라면 분명 좋습니다.

질문 2에서 두 프로토콜을 제공하는 것에 대한 하나의 가능한 반대는 일부 중개자 공격이 세션 중에 클라이언트 관점에서 https 요청/응답 통신을 http로 다시 라우팅한다는 것입니다. 대부분의 브라우저는 경고 메시지와 함께 중간 세션 재 경로를 방지하지만 침입자가 미리 대상 사이트를 알고있는 경우 사용자가 속임수를 쓰게 될 수도 있습니다. 특히 사용자가 사이트가 어느 모드에서나 작동 할 것으로 예상되는 경우 특히 그렇습니다. 이것 (그리고 아마 내가 모르는 더 나은 이유가 많다) 때문에 이미 어쨌든 작업을 마쳤으므로 https로 제한하는 것이 좋습니다.