PHP 개발자는 https/보안 소켓 계층 연결에 대해 무엇을 알아야 합니까?

Question

https 연결의 방법과 이유에 관해서는 나는 아무것도 모릅니다.분명히 비밀번호나 특히 신용 카드 정보와 같은 보안 데이터를 전송할 때 https는 중요한 도구입니다.그런데 그것에 대해 무엇을 알아야 합니까?개발자가 프로젝트에 이를 구현할 때 저지르는 가장 일반적인 실수는 무엇입니까?https가 단지 나쁜 생각일 때도 있나요?감사해요!

Answer 1

HTTPS 또는 SSL(Secure Sockets Layer) 인증서는 사이트에 제공되며 일반적으로 CA(인증 기관)에 의해 서명됩니다. CA(인증 기관)는 사이트에 대한 몇 가지 기본 세부 정보를 확인하고 사용을 인증하는 신뢰할 수 있는 제3자입니다. 브라우저에서.브라우저가 CA를 신뢰하는 경우 해당 CA가 서명한 모든 인증서를 신뢰합니다(이를 신뢰 체인이라고 함).

각 HTTP(또는 HTTPS) 요청은 두 부분으로 구성됩니다.요청과 응답.HTTPS를 통해 무언가를 요청하면 실제로 백그라운드에서 몇 가지 일이 발생합니다.

• 클라이언트(브라우저)는 "핸드셰이크"를 수행하여 서버의 공개 키와 ID를 요청합니다.
  • 이 시점에서 브라우저는 유효성을 확인할 수 있습니다(사이트 이름이 일치합니까?날짜 범위가 최신인가요?신뢰하는 CA에 의해 서명되었습니까?).CA에 연락하여 인증서가 유효한지 확인할 수도 있습니다.
• 클라이언트는 서버의 공개 키를 사용하여 암호화되어(서버만 해독할 수 있음) 새로운 사전 마스터 비밀을 생성하고 서버로 전송합니다.
• 서버와 클라이언트는 모두 이 사전 마스터 비밀을 사용하여 마스터 비밀을 생성한 다음 실제 데이터 교환을 위한 대칭 세션 키를 만드는 데 사용됩니다.
• 양측은 악수를 마쳤다는 메시지를 보낸다.
• 그런 다음 서버는 요청을 정상적으로 처리한 다음 세션 키를 사용하여 응답을 암호화합니다.

연결이 열려 있으면 각각에 대해 동일한 대칭 키가 사용됩니다.

새로운 연결이 설정되고 양쪽 모두 여전히 마스터 시크릿을 갖고 있는 경우 '축약된 핸드셰이크'를 통해 새 세션 키가 생성될 수 있습니다.일반적으로 브라우저는 닫힐 때까지 마스터 비밀을 저장하는 반면, 서버는 구성에 따라 몇 분 또는 몇 시간 동안 이를 저장합니다.

세션 기간에 대한 자세한 내용은 다음을 참조하세요. HTTPS 대칭 키는 얼마나 오래 지속되나요?

인증서 및 호스트 이름

인증서에는 HTTPS의 경우 도메인 이름인 CN(일반 이름)이 할당됩니다.CN은 정확하게 일치해야 합니다. 예를 들어 CN이 "example.com"인 인증서는 "www.example.com" 도메인과 일치하지 않으며 사용자는 브라우저에 경고를 받게 됩니다.

전에 SNI, 하나의 IP에서 여러 도메인 이름을 호스팅하는 것은 불가능했습니다.클라이언트가 실제 HTTP 요청을 보내기 전에 인증서를 가져오고 HTTP 요청에 호스트가 포함되어 있기 때문입니다.서버에 사용할 URL을 알려주는 헤더 라인이 있으면 서버는 주어진 요청에 대해 어떤 인증서를 제공할지 알 수 없습니다.SNI는 TLS 핸드셰이크의 일부에 호스트 이름을 추가하므로 클라이언트와 서버 모두에서 지원되는 한(2015년에는 널리 지원됨) 서버가 올바른 인증서를 선택할 수 있습니다.

SNI가 없더라도 여러 호스트 이름을 제공하는 한 가지 방법은 기본적으로 인증서가 유효한 추가 도메인인 SAN(주체 대체 이름)을 포함하는 인증서를 사용하는 것입니다.예를 들어 Google은 단일 인증서를 사용하여 많은 사이트를 보호합니다.

또 다른 방법은 와일드카드 인증서를 사용하는 것입니다."와 같은 자격증을 취득할 수 있습니다..example.com"인 경우 "www.example.com"과 "foo.example.com"은 모두 해당 인증서에 유효합니다.그러나 'example.com'은 '와 일치하지 않습니다..example.com"이고 "foo.bar.example.com"도 마찬가지입니다.인증서에 "www.example.com"을 사용하는 경우 "example.com"에있는 사람을 "www"로 리디렉션해야합니다. 대지.그들이 요청하면 https://example.com, 별도의 IP에서 호스팅하고 두 개의 인증서가 없으면 인증서 오류가 발생합니다.

물론 와일드카드와 SAN을 모두 혼합하여(CA에서 허용하는 경우) "example.com"과 SAN 모두에 대한 인증서를 얻을 수 있습니다.".example.com", "example.net" 및 ".example.net' 등이 있습니다.

양식

엄밀히 말하면 양식을 제출하는 경우 제출 URL이 https:// URL로 연결되는 한 양식 페이지 자체가 암호화되지 않아도 문제가 되지 않습니다.실제로 사용자는 작은 "잠금 아이콘"이 표시되지 않는 한 페이지를 제출하지 않도록 (적어도 이론적으로는) 교육을 받았으므로 이를 얻으려면 양식 자체도 HTTPS를 통해 제공되어야 합니다.

트래픽 및 서버 로드

HTTPS 트래픽은 동등한 HTTP 트래픽보다 훨씬 크며(암호화 및 인증서 오버헤드로 인해) 서버에 더 큰 부담을 줍니다(암호화 및 암호 해독).서버 부하가 심한 경우 HTTPS를 사용하여 제공되는 콘텐츠를 매우 선택적으로 선택하는 것이 바람직할 수 있습니다.

모범 사례

• 전체 사이트에 대해 HTTPS를 사용하지 않는 경우 필요에 따라 자동으로 HTTPS로 리디렉션되어야 합니다.사용자가 로그인할 때마다 HTTPS를 사용해야 하며, 세션 쿠키를 사용하는 경우 쿠키에는 다음이 있어야 합니다. 보안 플래그 세트.이는 세션 쿠키의 가로채기를 방지합니다. 이는 개방형(암호화되지 않은) Wi-Fi 네트워크의 인기를 고려할 때 특히 중요합니다.

• 페이지의 모든 리소스는 페이지에 사용되는 것과 동일한 구성표에서 나와야 합니다.페이지가 HTTPS로 로드될 때 http://에서 이미지를 가져오려고 하면 사용자에게 보안 경고가 표시됩니다.정규화된 URL을 사용해야 하거나, 또 다른 쉬운 방법은 호스트 이름을 포함하지 않는 절대 URL(예: src="/images/foo.png")을 사용하는 것입니다. 두 가지 모두에서 작동하기 때문입니다.

  • 여기에는 외부 리소스(예: Google Analytics)가 포함됩니다.

• HTTPS에서 HTTP로 변경할 때 POST(양식 제출)를 수행하지 마세요.대부분의 브라우저는 이를 보안 경고로 표시합니다.

Answer 2

SSL 전반에 대해 자세히 설명하지는 않겠습니다. gregmac은 이에 대해 훌륭한 작업을 수행했습니다. 아래를 참조하세요 ;-).

그러나 SSL/TLS 사용과 관련하여 발생하는 가장 일반적이고 중요한 실수는 다음과 같습니다(특히 PHP는 아님).

1. HTTPS를 적용해야 할 때 HTTP 허용
2. HTTPS 페이지에서 HTTP를 통해 일부 리소스 검색(예:이미지, IFRAME 등)

3. 의도치 않게 HTTPS 페이지에서 HTTP 페이지로 이동 - 여기에는 "about:blank"(이것이 IFRAME 자리 표시자로 사용되는 것을 본 적이 있음)와 같은 "가짜" 페이지가 포함되어 있어 불필요하고 불쾌하게 경고 팝업이 표시됩니다.

4. 안전하지 않은 오래된 SSL 버전을 지원하도록 구성된 웹 서버(예:SSL v2는 일반적이지만 끔찍하게 깨졌습니다.

5. 안전하지 않은 암호 스위트를 지원하도록 구성된 웹 서버 (기본적으로 절대적으로 암호화가없는 Null 암호를 보았습니다) (DITTO) (DITTO)

6. 자체 서명된 인증서 - 사용자가 사이트의 신원을 확인하는 것을 방지합니다.

7. HTTPS 페이지에 제출하는 경우에도 HTTP 페이지에서 사용자 자격 증명을 요청합니다.다시 말하지만, 이는 사용자가 서버에 비밀번호를 제공하기 전에 서버의 신원을 확인하는 것을 방지합니다.비밀번호가 암호화되어 전송되더라도 사용자는 자신이 가짜 사이트에 있는지, 또는 암호화되는지 여부를 알 수 없습니다.

8. 비보안 쿠키 - 보안 관련 쿠키(예: sessionId, 인증 토큰, 액세스 토큰 등) 해야 하다 "secure" 속성 세트로 설정됩니다.이건 중요하다!보안으로 설정되지 않은 경우 보안 쿠키(예:SessionId는 HTTP(!)를 통해 전송될 수 있으며 공격자는 이러한 일이 발생하도록 보장하여 세션 하이재킹 등을 허용할 수 있습니다.그 동안(직접적으로 관련되지는 않음) 쿠키에도 HttpOnly 속성을 설정하세요(일부 XSS를 완화하는 데 도움이 됨).

9. 과도한 권한이 부여된 인증서 - 하위 도메인이 여러 개 있지만 모두가 동일한 신뢰 수준에 있지는 않다고 가정해 보겠습니다.예를 들어 www.yourdomain.com, dowload.yourdomain.com 및 publicaccess.yourdomain.com이 있습니다.따라서 와일드카드 인증서를 사용하는 것을 고려해 볼 수도 있습니다....하지만 다른 서버에도 secure.yourdomain.com 또는 Finance.yourdomain.com이 있습니다.그러면 publicaccess.yourdomain.com이 secure.yourdomain.com을 가장할 수 있게 됩니다....이것이 괜찮은 경우가 있을 수 있지만 일반적으로 권한을 분리하는 것이 좋습니다...

지금 기억나는 건 이게 다인데 나중에 다시 편집할 수도 있겠네요...

SSL/TLS를 사용하는 것이 언제까지 나쁜 아이디어입니까? 특정 청중(단일 사용자 또는 등록 회원)을 대상으로 하지 않은 공개 정보가 있고 해당 정보를 특정 대상에서 검색하는 것에 대해 특별히 신경 쓰지 않는 경우 적절한 소스(예:주식 시세 값은 인증된 소스에서 나와야 합니다...) - 그러면 오버헤드가 발생할 실제 이유가 없습니다(성능뿐만 아니라...).개발/테스트/인증서/등).

그러나 공유 리소스가 있는 경우(예:동일한 서버) 귀하의 사이트와 더 민감한 다른 사이트 사이의 경우, 더 민감한 사이트가 여기에서 규칙을 설정해야 합니다.

또한 비밀번호(및 기타 자격 증명), 신용 카드 정보 등은 항상 SSL/TLS를 사용해야 합니다.

Answer 3

HTTPS 페이지에 있는 경우 페이지의 모든 요소가 HTTPS 주소에서 나오는지 확인하세요.즉, 요소에는 상대 경로가 있어야 합니다(예:"/images/banner.jpg") 프로토콜이 상속되거나 모든 페이지에서 확인하여 프로토콜을 찾고 이를 모든 요소에 사용해야 합니다.

참고:여기에는 모든 외부 리소스(예: Google Analytics 자바스크립트 파일)가 포함됩니다!

내가 생각할 수 있는 유일한 단점은 브라우저와 서버에 처리 시간이 추가된다는 것입니다(거의 무시할 수 있음).필요한 전송만 암호화하는 것이 좋습니다.

Answer 4

SSL 지원 사이트에서 작업할 때 가장 흔히 저지르는 실수는 다음과 같습니다.

1. 사이트가 사용자를 https로 페이지에서 http로 잘못 리디렉션합니다.
2. 필요할 때 사이트가 자동으로 https로 전환되지 않습니다.
3. https 페이지의 이미지 및 기타 자산은 http를 통해 로드되고 있으며, 이로 인해 브라우저에서 보안 경고가 트리거됩니다.모든 자산이 https를 지정하는 정규화된 URI를 사용하고 있는지 확인하세요.
4. 보안 인증서는 하나의 하위 도메인(예: www)에만 작동하지만 사이트는 실제로 여러 하위 도메인을 사용합니다.필요한 경우 와일드카드 인증서를 받으십시오.

Answer 5

언제든지 제안하겠습니다 어느 사용자 데이터는 데이터베이스에 저장되어 전달되며 https를 사용합니다.사용자 데이터가 평범하더라도 이 요구 사항을 고려하십시오. 이러한 일상적인 세부 정보 중 상당수는 해당 사용자가 다른 웹 사이트에서 자신을 식별하는 데 사용되기 때문입니다.은행에서 무작위로 묻는 보안 질문(예: 어느 거리에 사시나요?)을 모두 고려하세요.이는 주소 필드에서 정말 쉽게 가져올 수 있습니다.이 경우 데이터는 비밀번호로 간주되는 것이 아니지만 그럴 수도 있습니다.또한 다른 곳에서 보안 질문에 어떤 사용자 데이터가 사용될지 예측할 수 없습니다.또한 일반 웹 사용자(할머니를 생각해보세요)의 지능을 통해 그 작은 정보가 다른 곳에서 해당 사용자 비밀번호의 일부를 구성할 수도 있다고 기대할 수도 있습니다.

https를 사용하는 경우 하나의 포인터

사용자가 입력하면http://www.website-that-needs-https.com/etc/yadda.php자동으로 다음으로 리디렉션됩니다.https://www.website-that-needs-https.com/etc/yadda.php(개인적인 불만)

그러나 단순한 HTML 웹페이지를 수행하는 경우 이는 본질적으로 서버에서 사용자에게 단방향 정보 전송이므로 걱정하지 마십시오.

Answer 6

여기에 아주 좋은 팁이 모두 있습니다...그런데 뭔가 추가하고 싶은데요..
http 로그인 페이지를 제공하고 사용자 이름/패스를 게시한 후에만 https로 리디렉션하는 일부 사이트를 본 적이 있습니다.이는 https 연결이 설정되기 전에 사용자 이름이 일반 형식으로 전송된다는 의미입니다.

간단히 말해서 SSL 페이지에 게시하는 대신 SSL에서 로그인하는 페이지를 만드십시오.

Answer 7

나는 그것을 시도하는 것을 발견했다 <link> 존재하지 않는 스타일 시트로 인해 보안 경고가 발생했습니다.올바른 경로를 사용하면 자물쇠 아이콘이 나타납니다.