iOS 9 ATS와 작동하도록 IIS 7.5 SSL \ TLS를 구성하는 방법


11

문제 : iOS 9에서 ATS를 사용하므로 모바일 앱에서 더 이상 웹 서비스에 안전하게 연결할 수 없습니다.

배경 : iOS 9, 앱 전송 보안 소개

서버 설정 : Windows Server 2008 R2 SP1 (VM) IIS 7.5, digicert의 SSL 인증서. Windows 방화벽이 꺼져 있습니다.

키 RSA 2048 비트 (e 65537)

발급자 DigiCert SHA2 보안 서버 CA

RSA를 사용한 서명 알고리즘 SHA512

다음은 App Transport Security 요구 사항입니다.

서버는 최소한 TLS (Transport Layer Security) 프로토콜 버전 1.2를 지원해야합니다. 연결 암호는 순방향 보안을 제공하는 암호로 제한됩니다 (아래 암호 목록 참조). 인증서는 2048 비트 이상의 RSA 키 또는 256 비트 이상의 Elliptic-Curve와 함께 SHA256 이상의 서명 해시 알고리즘을 사용하여 서명해야합니다. (ECC) 키. 유효하지 않은 인증서는 하드 실패로 연결되지 않습니다. 허용되는 암호는 다음과 같습니다.

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

시도한 것 :

  1. 도메인이 작동하도록 모바일 앱에 예외를 추가했지만이 보안되지 않은 방법을 사용하고 싶지는 않지만 SSL을 수정하고 싶습니다.
  2. 사용 IIS 암호화를 '모범 사례'시도 'PCI'및 사용자 지정 설정을 사용할 수 있습니다. 심지어 위의 목록으로 암호화 제품군을 수정하고 순서를 바꾸려고했습니다. 각 시도 후에 서버가 재부팅되고 SSL Labs 가 실행되었습니다 (캐시를 지운 후). 나는 F 등급에서 A, 심지어 A-로 성공적으로 전환했지만 iOS 8 및 9에서만 보안 연결을 설정할 수 없었습니다. (NSURLErrorDomain 코드 = -1200 및 _kCFStreamErrorCodeKey = -9806) 여기에 이미지 설명을 입력하십시오
  3. VM을 복원하고 powershell 스크립트를 사용해 보았습니다 SSL Perfect Forward Secrecy 및 TLS 1.2를위한 IIS 설정 저는 파워 스크립트에서 필요한 것의 최소 목록으로 암호를 편집하는 두 번째 시도를했습니다.

결과 : 항상 비슷한 A 또는 A- 등급. iOS8과 iOS9는 보안 연결을 협상 할 수 없습니다. 핸드 셰이크 시뮬레이션 결과 Safari 및 iOS 제품에 대해 "프로토콜 또는 암호 제품군 불일치"가 발생합니다. 여기에 이미지 설명을 입력하십시오 여기에 이미지 설명을 입력하십시오

업데이트 Apple 지원팀과 협력 한 후 몇 가지 패킷 추적 캡처를 수행했습니다.

$ tcpdump -n -r trace.pcap
reading from file trace.pcap, link-type EN10MB (Ethernet)
client > server [S], seq 1750839998, win 65535, length 0
server > client [S.], seq 2461151276, ack 1750839999, win 8192, length 0
client > server [.], ack 1, win 4104, length 0
client > server [P.], seq 1:175, ack 1, win 4104, length 174
server > client [R.], seq 1, ack 175, win 0, length 0

처음 3 개의 패킷은 TCP 연결을 설정하는 클래식 SYN-SYN-ACK-ACK 3 방향 핸드 셰이크입니다. 네 번째 패킷은 iOS가 서버에 TLS Client Hello 메시지를 보내는 것으로, TCP 연결을 통한 TLS 연결 설정의 첫 번째 단계입니다. 나는이 메시지를 떼어 냈으며 충분히 합리적으로 보인다. 다섯 번째 패킷에서 서버는 단순히 RST를 전송하여 연결을 끊습니다.

IIS 7.5가 RST를 수행하는 이유를 아는 사람이 있습니까?


Digicert에 다시 연락하여 ECC 인증서에 대한 RSA 인증서를 변경했습니다. 이제 iOS 9가 안전하게 작동하지만 여러 구성 시도에서 iOS 8이 연결되지 않습니다.
RobDigital

답변:


5

질문은 오래되었지만 검색 중에 발견됩니다. 나는 같은 문제에 대한 해결책을 찾기 위해 시간을 보냈다. 따라서 나는 다른 사람들과 결과를 공유하기 위해 답을 작성하기로 결정했습니다.

짧은 대답 : IIS 암호를 사용하여 암호 그룹의 순서를 지정해서는 안됩니다. "기본값"버튼을 클릭하여 이전에 설정 한 순서를 제거한 다음 그룹 정책 ( "컴퓨터 구성"\ "관리 템플릿"\ "네트워크"\ "SSL 구성 설정")을 사용하여 로컬 정책을 통해 암호 제품군을 구성하는 것이 좋습니다.

"프로토콜 또는 암호 제품군 불일치"오류의 원인은 다음 중 하나 일 수 있습니다 .

  • 서버가 "불량 암호 모음"을 지원합니다
  • 서버가 일부 암호화 제품군을 지원하지 않으므로 반드시 지원해야하는 TLS 사양입니다.
  • 서버는 HTTP / 2를 지원하며 목록 에없는 다른 프로토콜 블랙리스트에 있는 일부 프로토콜이 있습니다 . 일반적으로 문제를 해결하기 위해 암호 제품군의 순서를 변경하면 충분합니다.

정확한 블랙리스트는 시스템마다 다를 수 있습니다. 인터넷에서 블랙리스트를 찾을 수 있습니다. 예를 들어 RFC 7540 (Hypertext Transfer Protocol Version 2 (HTTP / 2))의 부록 A 에는 하나의 목록이 있습니다. 암호 스위트는 TLS_RSA_WITH_AES_128_CBC_SHATLS 1.2 (참조를 위해 여기 )와 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS 1.3 (참조 여기에 ). 은 TLS_ECDHE_ECDSA_*단지 당신이 타원 곡선 인증서를 사용하는 것입니다 중요하다. 다른 아주 좋은 암호 모음 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256은 아직 Microsoft에 의해 구현되지 않았습니다. 또한 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA이전 시스템의 연결 TLS_RSA_WITH_AES_128_CBC_SHA을 지원하고 매우 오래된 시스템 (Android 2.3.7, Java 6u45, OpenSSL 0.9.8y)을 TLS_RSA_WITH_3DES_EDE_CBC_SHA지원하고 IE 8 / XP를 지원해야하는 경우에만 추가하도록 고려할 수 있습니다 . 예를 들어 오늘 사용할 수 있습니다

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS 1.0을 비활성화하고 TLS 1.1 을 사용하면 보안이 향상되거나

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

좋은 보안과 최고의 성능이 필요합니다.

예를 들어 문제를 해결하기 위해 다음과 같은 간단한 암호 세트를 설정할 수 있습니다.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

아래에는 Windows 10의 구성 예가 포함되어 있습니다. IIS 10 은 RSA 2048 키가있는 Qualys SSL Labs의 A + 등급과 Let 's Encrypt의 무료 SSL 인증서 를 갖도록 IIS 10을 구성했습니다 .

여기에 이미지 설명을 입력하십시오

DES 56/56, RC2 128/128, RC2 40/128, RC2 56/128, RC4 128/128, RC4 40/128, RC4 56/128, RC4 64/128, 트리플 DES 168/168, NULL, 레지스트리에서 MD5, 다중 프로토콜 통합 Hello, PCT 1.0, SSL 2.0, SSL 3.0 및 TLS 1.0 / 1.1을 수동으로 레지스트리에 표시합니다 ( KB245030 참조 ). 지금까지 IIS에서 TLS_FALLBACK_SCSV (다운 그레이드 공격)를 막을 수 없기 때문에 TLS 1.0 및 TLS 1.1 프로토콜 만 비활성화 했습니다 . 따라서 A + 등급 인 www.ssllabs.com 을 얻을 수 없습니다 . 단점이라고 생각하지만 TLS 1.2는 현재 매우 광범위하게 지원됩니다. 그런데 TLS 1.0 및 TLS 1.1 DisabledByDefault: 1에는 Enabled: 1을 사용할 수 있습니다 . 컴퓨터에서 SQL Server 2008/2012를 실행하면 도움이 될 수 있습니다. 웹 서버는 TLS 1.0 및 TLS 1.1을 사용하지 않지만 SQL Server는 사용합니다.

내 시간이 많이 걸리고 가장 큰 문제가되는 가장 중요한 단계는 Cipher Suites의 구성이었습니다. 사용하여 만들었습니다 gpedit.msc. "컴퓨터 구성"\ "관리 템플릿"\ "네트워크"\ "SSL 구성 설정"을 선택하고 "SSL 암호 그룹 순서"값을 다음과 같이 구성했습니다.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

위의 순서는 최적이 아니므로 위의 모든 프로토콜이 IIS 7.5에서 지원되는지 확실하지 않습니다 (Windows 10의 IIS 10.0을 사용했습니다). 그럼에도 불구하고 귀하의 문제는 Cipher Suite 목록과 관련이 있다고 확신합니다. Cipher Suite 목록을 실험하는 동안 설명한 것과 똑같은 문제가 있었기 때문입니다.

어쨌든 Group Polity에서 위의 설정을 구성하고 컴퓨터를 재부팅 한 후 ( gpupdate /force /target:computer테스트에서 충분하지 않은 경우) A + 등급과 "Handshake Simulation"부분의 테스트 결과 목록이 표시됩니다.

여기에 이미지 설명을 입력하십시오 여기에 이미지 설명을 입력하십시오 여기에 이미지 설명을 입력하십시오 여기에 이미지 설명을 입력하십시오

다음 클라이언트에서 iOS가 성공적으로 지원됨을 알 수 있습니다.

Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 8 / iOS 8.4
Safari 9 / iOS 9

TLS 1.2를 지원하지 않는 클라이언트는 현재 중요하지 않은 것 같습니다. 위의 구성은 레거시 클라이언트의 지원과 안전한 프로토콜의 사용 사이에서 좋은 절충안이라고 생각합니다.


IISCrypto로 자신을 감시하기 위해 +1,이 도구를 사용할 때 Windows에서 112 비트 3DES 비활성화 키를 잘못 설정하는 것을 보았습니다 ...
felickz

0

IIS Crypto 이미지가 최근 인 경우 설정을 그대로 유지하고 SHA, Diffie-Hellman 및 PKCS를 활성화하십시오. 그러면 A 등급이 부여되지만 iOS 8 이하 버전은 연결할 수 있습니다.


권장 한대로 SHA, Diffie-Hellman 및 PKCS를 활성화했습니다. 서버를 다시 시작하고 SSL 랩 테스트를 다시 수행하십시오. 불운. 여전히 ios 9에 연결할 수 없으며 SSL Labs에서 여전히 "프로토콜 또는 암호 제품군 불일치"가 발생합니다.
RobDigital

0

나는 며칠 동안 이것으로 고투했다. 특히 Xamarin Forms PCL을 사용하여 iOS 앱에서 연결하여 OAuth2 Bearer Token 인증을 사용하여 ASP.NET Web Api 2 rest 서비스에 연결했습니다.

결국 나를 위해 일한 것은 IIS Crypto의 모범 사례를 사용하는 것이 었습니다. 그런 다음 암호 제품군 순서로 설정 한 레지스트리 키를 편집하십시오.

KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Function

나는 다음과 같은 가치로 성공했습니다.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_DES_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

마지막 것은 Charles Proxy를 사용하여 발견되었으며 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256을 자동으로 협상했습니다. 나를 이끌어 낸 것은 Charles Proxy에서 연결에 성공했지만 (시뮬레이터 인증서가 설치된 상태) 그렇지 않으면 실패했습니다. 협상에 사용 된 제품군을 추가하면 트릭을 수행 할 수 있습니다. 프록시가 내 서버에서 지원하지만 iOS 클라이언트는 지원하지 않는 나머지 서비스와 재협상하는 것처럼 보입니다.

많은 암호화 제품군은 다양한 iOS / OSX 장치에 대한 선호 제품군의 ssllabs 사양에서 얻었습니다. 위의 값은 ssllabs에 따라 XP의 IE 6을 제외한 모든 항목 과 A 등급으로 악수해야합니다 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.