Copyright ©2016 PayPal Inc. All rights reserved. 홈 | 1

목차

홈 ................................................................... 2

TLS 1.2 및 HTTP/1.1 업그레이드 ............................................ 2 SSL 인증서 업그레이드 ..................................................... 2 HTTPS로 IPN 인증 포스트백 ................................................. 2 PayPal 보안 FTP 서버의 IP 주소 업데이트 ................................... 2 판매자 API 인증서 자격증명 업그레이드 ..................................... 3 클래식 NVP/SOAP API의 GET 메서드 사용 중단 ................................ 3 보안 모범사례 ............................................................. 3

TLS 1.2 및 HTTP/1.1 업그레이드 ........................................ 3

요약하면... ............................................................... 3 취해야 할 조치는 무엇인가요? .............................................. 4 기술 세부정보 ............................................................. 4 FAQ ....................................................................... 5

SSL 인증서 업그레이드 ................................................. 6

요약하면... ............................................................... 6 취해야 할 조치는 무엇인가요? .............................................. 7 기술 세부정보 ............................................................. 7 FAQ ....................................................................... 8

HTTPS로 IPN 인증 포스트백 ............................................ 10

요약하면... .............................................................. 10 취해야 할 조치는 무엇인가요? ............................................. 11 기술 세부정보 ............................................................ 11 FAQ ...................................................................... 12

보안 FTP 서버에 대한 IP 주소 업데이트 ................................. 12

요약하면... .............................................................. 12 취해야 할 조치는 무엇인가요? ............................................. 13 기술 세부정보 ............................................................ 14 FAQ ...................................................................... 14

판매자 API 인증서 자격증명 업그레이드 ................................. 15

요약하면... .............................................................. 15 취해야 할 조치는 무엇인가요? ............................................. 16 기술 세부정보 ............................................................ 16

2016년 판매자 보안 로드맵

Copyright ©2016 PayPal Inc. All rights reserved. 홈 | 2

FAQ ...................................................................... 17

클래식 API에 대한 GET 메서드 사용중단 ................................. 17

요약하면... .............................................................. 17 취해야 할 조치는 무엇인가요? ............................................. 18 기술 세부정보 ............................................................ 18 FAQ ...................................................................... 19

홈 내년을 대비하여 보안을 계획하고 고객님의 PayPal 통합 시스템이 최신 업계 표준에

부합하도록 아래에 나열된 요건을 검토하고 이행하시기 바랍니다.

서비스에 지장이 없도록 기재된 날짜까지 이러한 새로운 표준을 시스템에서 충족해야

합니다.

아래에 나오는 정보는 매우 기술적인 내용으로, 다음을 대상으로 합니다.

웹 호스팅 업체

전자 상거래 소프트웨어 제공업체

사내 웹 프로그래머/시스템 관리자

TLS 1.2 및 HTTP/1.1 업그레이드

PayPal 시스템에 연결되는 모든 외부 연결을 보호하는 데 사용하는 프로토콜을

업그레이드하고 있습니다. TLS 1.2(Transport Layer Security 버전 1.2)와

HTTP/1.1(Hypertext Transfer Protocol 버전 1.1)이 2016년 PayPal과의 통신에서

의무사항이 되었습니다. 사용하는 환경이 TLS 1.2와 HTTP/1.1을 지원하는지 확인하고

필요한 경우 적절하게 업데이트해야 합니다. 자세한 정보를 보려면 여기를

클릭하세요.

조치 기한: 2016년 6월 17일

SSL 인증서 업그레이드

PayPal은 웹 사이트와 API 엔드포인트를 보호하는 데 사용되는 SSL 인증서를

업그레이드 중입니다. 이러한 새 인증서에는 SHA-256 알고리즘과 VeriSign의 2048비트

G5 루트 인증서를 사용하여 서명합니다. 사용 환경에서 SHA-256 서명 알고리즘 사용을

지원하는지 확인하고 VeriSign G2 루트 인증서를 사용하는 SSL 연결 사용을 중단해야

합니다. 자세한 정보를 보려면 여기를 클릭하세요.

조치 기한: 2016년 6월 17일

HTTPS로 IPN 인증 포스트백

PayPal의 IPN(즉시 결제 알림) 서비스를 사용 중인 경우 인증을 위해 메시지를

PayPal에 다시 게시할 때 HTTPS를 사용하는지 확인해야 합니다. HTTP 포스트백이 더

이상 지원되지 않습니다. 자세한 정보를 보려면 여기를 클릭하세요.

조치 기한: 2016년 9월 30일

PayPal 보안 FTP 서버의 IP 주소 업데이트

PayPal 통합이 파일을 PayPal의 보안 FTP 보고/배치 서버와 시스템적으로 교환하도록

설정된 경우, 서버의 IP 주소가 변경됨을 알아두세요. 통합이 이전 IP 주소로 하드

코딩된 경우 서비스에 지장이 발생하지 않도록 하려면 즉시 업그레이드해야 합니다.

자세한 정보를 보려면 여기를 클릭하세요.

Copyright ©2016 PayPal Inc. All rights reserved. TLS 1.2 및 HTTP/1.1 업그레이드 | 3

2016년 4월 14일 부로 완료

판매자 API 인증서 자격증명 업그레이드

클래식 API에서 사용할 수 있도록 PayPal에서 발급한 API 인증서 자격증명을 SHA-

256이 서명된 2048비트 인증서로 업그레이드 중입니다. 현재 API 인증서 자격증명을

사용하여 PayPal에 연결하는 경우 계정 프로필을 통해 새로운 API 인증서를 생성하고

이를 모든 API 요청에 사용해야 합니다. 자세한 정보를 보려면 여기를 클릭하세요.

이행 기간: 2016년 1월 31일 ~ 2018년 1월 1일(인증서 만료 날짜에 따라 다름)

클래식 NVP/SOAP API의 GET 메서드 사용 중단

PayPal은 더 이상 클래식 NVP/SOAP API의 GET HTTP 요청 메서드 사용을 지원하지

않습니다. 현재 이러한 API를 사용하는 경우 API 요청이 POST HTTP 요청 메서드만

사용하는지 확인해야 합니다. 자세한 정보를 보려면 여기를 클릭하세요.

조치 기한: 2016년 9월 30일

보안 모범사례

미래에도 경쟁력을 갖춘 통합을 구현하기 위해서는 꾸준한 노력이 필요합니다.

PayPal에서 이를 구현할 수 있도록 도와드리겠습니다. 보안 모범사례를 보려면 여기를

클릭하세요.

TLS 1.2 및 HTTP/1.1 업그레이드

요약하면...

판매자와 파트너는 HTTPS를 사용하여 PayPal 서버에 안전하게 연결합니다. PayPal은

TLS(전송 계층 보안) 프로토콜을 사용하여 이러한 통신을 암호화합니다. PayPal은

시스템을 보안하고 업계 모범사례를 준수하기 위해 모든 HTTPS 연결에 대해 TLS 1.2를

요구하도록 서비스를 업데이트하는 중입니다. 이때 또한 모든 연결에 HTTP/1.1이

요구됩니다.

서비스에 지장이 발생하지 않도록 이러한 변경에 시스템이 준비가 되어 있는지

2016년 6월 17일까지 확인해야 합니다.

TLS 1.2_Upgrade_White_Paper.pdf

백서: PayPal의 2016년 6월 TLS 1.2 업그레이드에 대한 기초

Copyright ©2016 PayPal Inc. All rights reserved. TLS 1.2 및 HTTP/1.1 업그레이드 | 4

취해야 할 조치는 무엇인가요?

향후 수동적인 버전 변경을 피하려면 항상 최신 버전을 받아들여 응답하도록

시스템을 코딩하는 것이 좋습니다.

기술 세부정보

Sandbox 엔드포인트 - 준비 완료

PayPal Sandbox 엔드포인트는 프로덕션 엔드포인트가 따르게 될 최신 보안 표준으로

구성되어 있습니다. 이러한 엔드포인트를 사용하여 프로덕션 엔드포인트를

업데이트하기 전에 코드가 필수 표준을 지원하는지 확인할 수 있습니다. 이러한

엔드포인트는 TLS 1.2 및 HTTP/1.1 연결만 허용합니다.

api.sandbox.paypal.com

호스팅 되어있나요?

아니요

시스템에서 TLS 1.2와 HTTP/1.1을 이미

지원하고 있나요?

(이에 대한 자세한 내용은 아래 기술

정보 참조)

아니요

TLS 1.2와 HTTP/1.1을 지원하도록

시스템 업그레이드

이전 버전의 TLS 또는 HTTP를 하드

코딩했나요?

예

항상 PayPal 엔드포인트에서 지원하는

최신 버전의 TLS 및 HTTP를 사용하도록

코드를 업데이트하세요.

아니요

좋습니다! 조치가 필요하지 않습니다.

예

좋습니다! 조치가 필요하지 않습니다.

예

제공업체가 TLS 1.2와 HTTP/1.1을

지원할 수 있도록 연락하세요.

Copyright ©2016 PayPal Inc. All rights reserved. TLS 1.2 및 HTTP/1.1 업그레이드 | 5

api-3t.sandbox.paypal.com

api-aa.sandbox.paypal.com

api-aa-3t.sandbox.paypal.com

svcs.sandbox.paypal.com

pointofsale.sandbox.paypal.com

ipnpb.sandbox.paypal.com

www.sandbox.paypal.com

프로덕션 엔드포인트 - 2016년 6월 17일 이후 준비 완료

프로덕션 엔드포인트는 TLS 1.2 및 HTTP/1.1 연결만 허용하게 됩니다.

api.paypal.com

api-3t.paypal.com

api-aa.paypal.com

api-aa-3t.paypal.com

svcs.paypal.com

pointofsale.paypal.com

ipnpb.paypal.com

www.paypal.com

https://tlstest.paypal.com에서 시스템을 확인하세요!

PayPal은 시스템의 최신 보안 표준 지원 여부를 확인할 수 있도록 새로운

엔드포인트(https://tlstest.paypal.com)를 만들었습니다. 이 엔드포인트는 PayPal

엔드포인트가 따르게 될 모든 보안 표준을 지원합니다.

성공 시: https://tlstest.paypal.com에 성공적으로 연결되면 본문에

“PayPal_Connection_OK” 텍스트가 포함된 HTTP 200 응답이 반환됩니다.

실패 시: 시스템에서 지원되지 않는 항목에 따라 다음 오류 중 하나가 발생합니다.

o HTTPS – tlstest.paypal.com에서 본문에 “오류! 연결이 HTTPS가 아닙니다.

https://tlstest.paypal.com을 사용하세요.”라는 텍스트가 포함된 HTTP 400 응답을

반환합니다.

o HTTPS/1.1 – tlstest.paypal.com에서 본문에 “오류! 연결에서 HTTP/1.0 프로토콜을

사용하고 있습니다. HTTP/1.1을 사용하세요.”라는 텍스트가 포함된 HTTP 400 응답을

반환합니다.

o TLS 1.2(SHA-256) - 코드에서 SSL 연결 오류를 표시합니다.

추가로 도움을 제공하기 위해 공통 환경을 위한 프로그래밍 언어별 테스트 참고

사항을 모았습니다. Android를 포함하여 Java 환경에 큰 영향을 줄 것으로

예상합니다. .NET, PHP, Ruby, Python, Node.js를 비롯한 다른 환경에도 영향을 줄 수

있습니다. 자세한 내용은 다음을 참조하세요.

FAQ

PCI 위원회에서 기한을 변경했으므로 PayPal에서도 날짜를 변경할 예정인가요?

아니요. 아시다시피 결제카드산업 보안표준위원회(PCI 위원회)는 최근에 2016년에서

2018년으로 결제 처리자가 이러한 변경을 해야 하는 기한을 연장했습니다. 그러나

계속해서 업계를 선도하여 최고의 보안 표준을 제공하기 위해 PayPal은 올해 이러한

보안 표준 구현을 그대로 진행하기로 결정했습니다.

언어별 테스트 메모

Copyright ©2016 PayPal Inc. All rights reserved. SSL 인증서 업그레이드 | 6

임시 Sandbox 엔드포인트는 어떻게 된 건가요?

다음 엔드포인트는 Sandbox 엔드포인트가 업데이트되기 전에 새로운 표준을 테스트할

수 있도록 만들어졌습니다. 이제 Sandbox 엔드포인트가 업데이트되었으므로 이러한

테스트 엔드포인트를 사용하지 않아야 하며 2016년 2월 29일에 사용이 중단됩니다.

test-api.sandbox.paypal.com

test-api-3t.sandbox.paypal.com

test-svcs.sandbox.paypal.com

test-ipnpb.sandbox.paypal.com

SSL 인증서 업그레이드

요약하면...

SHA-256을 지원합니다. PayPal은 모든 Live 및 Sandbox 엔드포인트에서 SSL 인증서를 SHA-

1에서 더 강력하고 견고한 SHA-256 알고리즘으로 업그레이드하고 있습니다. 따라서 SHA-256을

사용하는 인증서를 지원하도록 PayPal 통합 시스템을 업데이트하셔야 합니다.

VeriSign G2 루트 인증서 사용을 중단합니다. PayPal은 업계 표준에 따라 신뢰 유효성 검사를

위해 VeriSign G2 루트 인증서가 필요한 보안 연결을 더 이상 사용하지 않습니다. G5 루트

인증서로 인증서/신뢰 체인을 서명해야 하는 보안 연결 요청만 성공하게 됩니다.

이러한 변경 사항에 대한 자세한 내용은 판매자 보안 시스템 업그레이드 안내서를

참조하세요. 인터넷 보안에 대한 기본 소개 자료로는 SSL 인증서와 공개 키 암호화에

대한 간략한 비디오를 권장합니다.

이러한 업데이트는 업계 전반적인 보안 업그레이드에 부응하기 위한 것으로,

PayPal만 시행하는 것이 아닙니다. 업데이트를 통해 사용자의 웹 사이트와

PayPal 웹 사이트 및 API(애플리케이션 프로그래밍 인터페이스)와의 상호

통신을 안전하게 보호할 수 있습니다.

서비스에 지장이 발생하지 않도록 이러한 변경에 시스템이 준비가 되어 있는지

2016년 6월 17일까지 확인해야 합니다.

Copyright ©2016 PayPal Inc. All rights reserved. SSL 인증서 업그레이드 | 7

취해야 할 조치는 무엇인가요?

시스템이 변경될 요건을 지원하는지 여부를 명확하게 판단하는 방법은 웹

개발자나 시스템 관리자가 PayPal Sandbox를 사용하여 통합 테스트를

실행하도록 하는 것입니다. Sandbox로 테스트 했을 때 실패했다면 다음

정보를 모두 검토하고 시스템 환경을 업그레이드해야 합니다.

기술 세부정보

Sandbox 엔드포인트 - 준비 완료

PayPal Sandbox 엔드포인트는 프로덕션 엔드포인트가 따르게 될 최신 보안 표준으로

구성되어 있습니다. 이러한 엔드포인트를 사용하여 프로덕션 엔드포인트를

업데이트하기 전에 코드가 필수 표준을 지원하는지 확인할 수 있습니다. 다음

엔드포인트는 새로운 SHA-256, 2048비트 인증서로 업그레이드되었습니다.

api.sandbox.paypal.com

api-3t.sandbox.paypal.com

호스팅 되어있나요?

아니요

시스템이 SHA-256을 이미 지원하고

있나요?

(테스트 방법에 대해서는 아래 PDF

문서를 참조하세요.)

아니요

SHA-256 호환성을 위해 시스템

업그레이드

시스템이 신뢰 유효성 검사에 G5

루트 인증을 이미 사용하고 있나요?

(테스트 방법에 대해서는 아래 PDF

문서를 참조하세요.)

아니요

G5 루트 설치

예

좋습니다! 조치가 필요하지

않습니다.

예

좋습니다! 조치가 필요하지

않습니다.

예

SHA-256과 G5와 호환될 수 있도록

제공업체에 연락하세요.

Copyright ©2016 PayPal Inc. All rights reserved. SSL 인증서 업그레이드 | 8

api-aa.sandbox.paypal.com

api-aa-3t.sandbox.paypal.com

svcs.sandbox.paypal.com

pointofsale.sandbox.paypal.com

ipnpb.sandbox.paypal.com

www.sandbox.paypal.com

프로덕션 엔드포인트 - 준비 완료

다음 프로덕션 엔드포인트는 새로운 SHA-256, 2048비트 인증서로

업그레이드되었습니다.

pointofsale.paypal.com

www.paypal.com

프로덕션 엔드포인트 - 2016년 6월 17일 이후 준비 완료

다음 프로덕션 엔드포인트는 2016년 6월 17일 이후 새로운 SHA-256, 2048비트

인증서로 업그레이드됩니다.

api.paypal.com

api-3t.paypal.com

api-aa.paypal.com

api-aa-3t.paypal.com

svcs.paypal.com

ipnpb.paypal.com

이러한 변경 사항에 대한 자세한 내용은 판매자 보안 시스템 업그레이드 안내서를

참조하세요.

FAQ

SHA-1은 어떻게 된 건가요?

SHA-1을 폐기하기로 한 결정은 2014년 10월 16일에 CA/브라우저 포럼에서

정해졌습니다.

G5 루트 인증서와 SHA-256 인증서를 모두 동시에 업데이트할 수 있나요?

예. 먼저 VeriSign G5 루트 인증서가 키스토어에 있는지 확인합니다. 없으면

다운로드하여 추가합니다. 다음으로, SHA-256 인증서를 처리하도록 SSL 소프트웨어를

업데이트합니다.

시스템에서 인증서를 키스토어에 설치하도록 요구합니다. PayPal에서 배포할 새 인증서를 어디서 구할

수 있나요?

올해 말에 배포될 새 인증서는 현재의 프로덕션 인증서와 함께 여기에서 찾을 수

있습니다.

내 PayPal 통합 시스템이 영향을 받는지 어떻게 알 수 있나요?

앞으로 있을 Live 환경을 변경하기 전에 Sandbox 환경을 변경했으므로 Sandbox에서

통합 시스템을 확인할 수 있습니다. 또한 Sandbox 엔드포인트의 ‘test-*’ 버전을

만들었습니다(위 세부정보 참조).

Sandbox 환경에서 이러한 오류 메시지나 이와 유사한 오류 메시지가 표시되면 Live

환경으로 변경하기 전에 통합 시스템을 업데이트해야 합니다.

“요청된 대상에 대한 유효한 인증서 경로를 찾을 수 없음”

“SSLException: 사용 설정된 SSL 암호 그룹에 대응하는 인증서나 키가 없음”

“경보 핸드셰이크 실패”

Copyright ©2016 PayPal Inc. All rights reserved. SSL 인증서 업그레이드 | 9

“SSL CA 인증서 문제(경로 또는 액세스 권한)”

SDK를 업데이트해야 하나요?

아니요. 하지만 최신 버전의 SDK를 사용하고 있는지 확인하는 것이 좋습니다. 최신

버전이 아니라면 제공된 지침에 따라 SDK를 업데이트하세요. PayPal SDK를 사용하지

않는 경우 제공업체에 지원을 문의해야 합니다.

인증서 업그레이드는 필수가 아니지만 TLS 1.2 업그레이드는 해야 할 수 있습니다. 자세한

내용은 TLS 마이크로사이트를 참조하세요.

예정된 PayPal 테스트 중에 SSL 핸드셰이크 오류가 간헐적으로 발생하면 어떻게 해야 하나요?

이후 지장이 발생하지 않도록 PayPal 통합 시스템을 바로 변경하는 것이 중요합니다.

영구적인 변경을 요청하기 전에 PayPal Sandbox 또는 Payflow Pilot 환경에서

빌드/테스트해야 합니다. 자세한 내용은 판매자 보안 시스템 업그레이드 안내서를

참조하세요.

포스트백 유효성 검사에서 실패한 IPN을 다시 보내려면 어떻게 하나요?

PayPal 계정에서 IPN을 다시 보낼 수 있습니다. 세부 안내는

developer.paypal.com에서 IPN 메시지 다시 전송을 참조하세요. 참고: 참고: IPN이

해당 서버로 성공적으로 전송되었으므로 “실패”로 표시되지 않습니다. 그러나

유효성 검사를 받기 위한 포스트백에서 실패했습니다.

Sandbox 환경에서 IPN을 테스트하려면 어떻게 하나요?

developer.paypal.com에서 IPN 테스트를 보고 특히 "Sandbox 테스트"를 참조하세요.

추가 지원이 필요한 경우 PayPal 기술 지원 페이지에서 티켓을 열면 됩니다. 제품

옵션에는 목록 상단에 고정되어 있는 "보안 변경(TLS/인증서)"을 선택하세요.

9월 30일에 IPN에 문제가 발생하기 시작했습니다. 어떻게 된 건가요?

IPN(즉시 결제 알림)에 www.paypal.com을 사용하고 있고 SHA-256 호환되지 않는

서버/OS가 있는 경우 PayPal 통합 시스템에 영향을 주지 않도록 다음 옵션을 고려해

보세요.

장기적 해결 방법: 호환되는 서버/OS 구성으로 업그레이드하세요. 파트너, 쇼핑 카트 또는

타사 호스팅이 IPN 수신기/검사기를 호스트하는 경우, 연결에 지장이 없도록 필요한 단계를

수행했는지 이들에게 확인하세요. 아래 나열된 리소스와 같은 온라인 리소스에서 호환 구성에

대한 세부정보를 검토한 다음 고객님의 웹 사이트 기술지원팀에 개발 지원에 대해 문의하세요.

o DigiCert의 SHA-2 호환성 안내서

o Symantec에서 지원하는 브라우저 및 서버 목록

o GlobalSign의 SHA-256 호환성 안내서

임시 해결 방법: ipnpb.paypal.com으로 마이그레이션합니다. 이 엔드포인트는 2016년

2분기까지 SHA-1에 남게 되며, 대체 IPN 처리 포인트로 사용될 수 있습니다. 웹 사이트 기술

팀에 문의하여 개발 지원을 받으세요.

o IPN(즉시 결제 알림)을 설정하려면 어떻게 하나요?

o IPN 통합 안내서

o IPN 코드 샘플

www.ipnpb.com이 SHA-256으로 업데이트되면 이 방법은 더 이상 사용할 수

없습니다. 이 업그레이드는 2016년 2분기 중 이루어지므로 그전에 옵션 1로

마이그레이션해야 합니다.

SHA-256 준수 전 IPN 보기: SHA-256을 준수할 때까지 프로필에 액세스하여 IPN 상태를

수동으로 추적할 수 있습니다.

o IPN 기록을 확인하려면 어떻게 해야 하나요?

Copyright ©2016 PayPal Inc. All rights reserved. HTTPS로 IPN 인증 포스트백 | 10

SHA-256 준수 이후 IPN 다시 보내기: SHA-256을 준수한 후에 누적된 IPN을 백오피스에

재전송하도록 트리거할 수 있습니다.

o IPN 메시지 재전송

HTTPS로 IPN 인증 포스트백

요약하면...

판매자와 파트너는 IPN(즉시 결제 알림)을 사용하여 PayPal 거래와 관련된 이벤트

알림을 받습니다. IPN 메시지 서비스를 사용하려면 이러한 메시지 수신을 인정하고

확인해야 합니다. 이 과정에 PayPal로 인증할 메시지를 다시 게시하는 작업이

포함됩니다. 이전에는 이러한 포스트백에 HTTP를 사용하는 것이 허용되었습니다.

앞으로는 보안 강화를 위해 PayPal에 포스트백하는 경우에만 HTTPS를 사용할 수

있습니다. 이때, PayPal에서 판매자의 IPN 수신기로 보내는 아웃바운드 IPN 호출에

대해 HTTPS가 요구되지 않습니다.

서비스에 지장이 발생하지 않도록 이러한 변경에 시스템이 준비가 되어 있는지

2016년 9월 30일까지 확인해야 합니다.

Copyright ©2016 PayPal Inc. All rights reserved. HTTPS로 IPN 인증 포스트백 | 11

취해야 할 조치는 무엇인가요?

PayPal은 HTTPS를 요구하는 것 외에도 모든 외부 엔드포인트에 대한 보안

표준을 업그레이드하고 있습니다. 현재 시스템에서 이러한 요건을 지원하는지

확인해야 합니다. 자세한 내용은 SSL 및 TLS 마이크로 사이트에서 확인할 수

있습니다.

기술 세부정보

ipnpb.paypal.com과 ipnpb.sandbox.paypal.com 엔드포인트는 HTTPS 연결만

허용합니다. 현재 www.paypal.com을 사용하는 경우 HTTPS를 사용하도록 코드를

업데이트할 때 ipnpb.paypal.com으로 이동해야 합니다.

준비 완료

IPN 포스트백에 사용하는 경우 www.sandbox.paypal.com은 HTTPS 연결만 허용합니다.

현재 PayPal의 IPN(즉시 결제 알림) 서비스를

사용하고 계시나요?

예

현재 IPN 메시지를 인증하기 위해 포스트백을

수행할 때 HTTPS를 사용하나요?

아니요

PayPal로 포스트백 메시지를 보낼 때 HTTPS를

사용하도록 코드를 업데이트하세요.

PayPal은 현재 두 엔드포인트

www.paypal.com과 ipnpb.paypal.com에서 IPN

포스트백을 지원합니다. 앞으로

ipnpb.paypal.com을 사용하실 것을 강력하게

권장합니다.

예

좋습니다!

아래 참고를 확인하세요.

아니요

조치가 필요하지 않습니다.

Copyright ©2016 PayPal Inc. All rights reserved. 보안 FTP 서버에 대한 IP 주소 업데이트 | 12

2016년 9월 30일

IPN 포스트백에 사용하는 경우 www.paypal.com은 HTTPS 연결만 허용합니다.

FAQ

PayPal에서 이렇게 변경하는 이유는 무엇인가요?

PayPal은 판매자와 파트너가 프로그래밍 방식으로 연결하는 데 사용하는 외부

엔드포인트를 업그레이드하고 있습니다. 이러한 변경 사항 중 하나는 PayPal 시스템에

연결할 때 모든 정보가 안전하게 전송되도록 하기 위해 HTTPS만 사용하도록 합니다.

IPN 메시지에는 안전하게 전달해야 하는 고객 및 고객 거래에 대한 민감한 정보가

포함되어 있습니다.

PayPal에서 모든 외부 엔드포인트에 적용될 업그레이드된 보안 표준은 무엇인가요?

PayPal은 모든 외부 엔드포인트를 최신 업계 표준으로 업그레이드하고 있습니다.

HTTP 1.1 이상

HTTPS만 허용

TLS 1.2 이상만 허용

VeriSign의 G5 루트로 서명된 2048비트, SHA-256 인증서

자세한 내용은 SSL 및 TLS 마이크로사이트를 참조하세요.

보안 FTP 서버에 대한 IP 주소 업데이트

요약하면...

판매자와 파트너는 PayPal의 보안 FTP 보고/배치 서버를 사용하여 체계적으로

PayPal과 파일을 교환합니다. 이러한 서버는 일반적으로 일별 보고서를 불러오는 데

사용하지만, 일괄 처리, 계정 만들기 및 관리, 분쟁 처리를 위해 파일을 제출하고

검색하는 데에도 사용합니다. 안정성과 보안 강화를 위해 이러한 보안 FTP 서버를

새로운 IP 주소로 이전했습니다.

이 변경 사항은 2016년 4월 14일 부로 완료됨

Copyright ©2016 PayPal Inc. All rights reserved. 보안 FTP 서버에 대한 IP 주소 업데이트 | 13

취해야 할 조치는 무엇인가요?

PayPal 보안 FTP 서버에 연결된

시스템이 있나요?

예

DNS(Domain Name Service)를

사용하여 올바른 IP 주소를

확인하나요?

아니요

연결을 하거나 관련 방화벽 규칙을 처리하기 위해 하드

코딩된 IP 주소를 사용하지 마세요.

해당 서버 이름 엔드포인트 사용으로 전환하여 DNS에서 IP

주소를 확인할 수 있도록 허용하는 것이 좋습니다. 하드

코딩된 IP 주소를 사용해야 하는 경우 새 IP 주소가

활성화되고 기존 IP 주소가 비활성화되기 전에 새 IP 주소로

전환해야 합니다.

특정 IP 주소를 기반으로 하여

PayPal의 보안 FTP 서버에 대한

액세스를 허용하는

방화벽 규칙이 있나요?

예

새 IP 주소를 방화벽 규칙에 추가해야

합니다.

아니요

좋습니다! 조치가 필요하지 않습니다.

예

좋습니다! 조치가

필요하지 않습니다.

아니요

조치가 필요하지 않습니다.

Copyright ©2016 PayPal Inc. All rights reserved. 보안 FTP 서버에 대한 IP 주소 업데이트 | 14

PayPal의 보안 FTP 서버에 액세스하는 데 사용한 클라이언트에 따라, 액세스

중인 엔드포인트와 연결된 호스트 키를 수동으로 업데이트할 것인지 묻는

메시지가 표시될 수 있습니다. 예를 들어, Linux/Unix 시스템 명령줄을 통해

시스템적으로 또는 수동으로 연결하는 경우 엔드포인트와 연결된 기존 항목을

지워서 known_hosts 파일을 업데이트해야 할 수 있습니다.

기술 세부정보

다음 엔드포인트는 PayPal의 보안 FTP 보고/배치 서버에 액세스하는 데 사용할 수

있고, IP 주소 변경의 영향을 받습니다.

reports.paypal.com

batch.paypal.com

accounts.paypal.com

disputes.paypal.com

준비 완료

2016년 3월 20일에 다음 IP 주소가 PayPal의 보안 FTP 엔드포인트에 대한 DNS

레코드에 추가되었습니다.

173.0.84.139

173.0.88.139

2016년 4월 14일에 다음 IP 주소가 PayPal의 보안 FTP 엔드포인트에 대한 DNS

레코드에서 삭제되었습니다.

173.0.84.161

173.0.84.198

173.0.88.161

173.0.88.198

특정 IP 주소를 기반으로 하여 PayPal의 보안 FTP 서버에 대한 액세스를 허용하는

방화벽 규칙이 있는 경우 규칙에 다음 IP 주소를 포함해야 합니다. 이 IP 주소는

일반적으로 보안 FTP 엔드포인트에 대한 DNS 항목에 없지만 필요에 따라 유지 보수와

재해 복구를 위해 추가될 수 있습니다.

66.211.168.93

2016년 5월 12일 목요일

다음 IP 주소는 더 이상 PayPal의 보안 FTP 서버로 라우팅되지 않습니다.

173.0.84.161

173.0.84.198

173.0.88.161

173.0.88.198

보안 FTP를 몇 시간 동안 사용하지 못할 수 있습니다. 세부정보는 나오는 대로

알려드리겠습니다.

FAQ

이 변경 사항에 대해 취해야 할 조치는 무엇인가요?

시스템이 PayPal 보안 FTP 보고 또는 배치 서버에 액세스할 경우 관련 기술 및 운영

팀에 변경 사실을 알리세요. 연결이 DNS를 사용하여 서버를 참조하도록 해야 합니다.

시스템이 하드 코딩된 IP 주소를 사용할 경우 즉시 업데이트해야 합니다.

Copyright ©2016 PayPal Inc. All rights reserved. 판매자 API 인증서 자격증명 업그레이드 | 15

PayPal에서 하드 코딩보다 DNS를 권장하는 이유는 무엇인가요?

PayPal은 앞으로 이러한 서비스와 기타 서비스를 다른 IP 주소로 이전할 수 있습니다.

수동으로 변경할 필요가 없도록 하기 위해 PayPal은 DNS를 사용할 것을 권장합니다.

Sandbox 보안 FTP 환경은 새 IP 주소를 사용하게 되나요?

그렇지 않습니다.

보안 FTP 서버에 액세스하려고 하면 “경고: 원격 호스트 ID가 변경되었습니다!”라는 오류 메시지가

표시되는 이유는 무엇인가요?

연결하려는 보안 FTP 엔드포인트에 대한 기존 항목이 known_hosts 파일에 있을 수

있습니다. 오류를 해결하려면 보안 FTP 엔드포인트에 대한 항목을 known_hosts

파일에서 삭제하세요.

판매자 API 인증서 자격증명 업그레이드

요약하면...

PayPal의 기존 API 인증서 자격증명은 10년 후에 만료되는 1024비트 SHA-1

인증서입니다. 2016년 2월 4일부터 발급되는 모든 PayPal API 인증서 자격증명은

2048비트 SHA-256 인증서로, 3년마다 만료됩니다. 따라서 모든 판매자가 지금부터

2018년 1월 1일까지 새 2048비트 인증서로 업그레이드해야 합니다.

서비스에 지장이 발생하지 않도록 2016년 2월 4일부터 2018년 1월 1일까지 이러한

변경에 시스템이 준비가 되어 있는지 확인해야 합니다.

Copyright ©2016 PayPal Inc. All rights reserved. 판매자 API 인증서 자격증명 업그레이드 | 16

취해야 할 조치는 무엇인가요?

기술 세부정보

인증서 유형 확인

새로운 유형의 API 인증서가 있는지 확인하는 가장 쉬운 방법은 계정 프로필에서 API

인증서 관리 페이지로 이동하는 것입니다.

PayPal 계정에 로그인합니다.

프로필 > 나의 판매 도구 > API 액세스 > API 인증서 보기로 이동합니다.

현재 API 인증서의 경우:

o 만료 날짜가 요청 날짜로부터 3년 후인 경우 최신 유형이므로 문제가 없습니다.

o 만료 날짜가 요청 날짜로부터 10년 후인 경우 2018년 1월 1일 전까지 교체해야 합니다.

PayPal에서 다운로드한 API 인증서가 있는 경우 OpenSSL을 사용하여 새로운 인증서

유형인지 확인할 수 있습니다.

openssl x509 -text -noout -in cert_key_pem.txt

2018년 1월 1일까지 기존 API 인증서 교체

PayPal 계정에 로그인합니다.

프로필 > 나의 판매 도구 > API 액세스 > API 인증서 보기로 이동합니다.

만료 날짜 옆에 있는 인증서 갱신 버튼을 클릭합니다.

o 그러면 두 번째 API 인증서가 만들어 집니다.

API 인증서 자격증명을

사용하시나요?

예

현재 인증서가 2048비트인가요?

아니요

2018년 1월 1일 전까지 새

인증서를 생성하고 이를

사용하도록 시스템을

업데이트해야 합니다.

예

좋습니다! 조치가 필요하지

않습니다.

아니요

좋습니다! 조치가 필요하지

않습니다.

Copyright ©2016 PayPal Inc. All rights reserved. 클래식 API에 대한 GET 메서드 사용중단 | 17

o 두 인증서를 동시에 사용할 수 있으므로 중단 시간을 최소화하면서 시스템을 업데이트할

수 있습니다.

API 인증서 자격증명 갱신에 대한 세부정보는 다음을 참조하세요.

FAQ

PayPal에서 API 인증서 자격증명을 변경하는 이유는 무엇인가요?

결제 업계 표준이 더 안전한 2048비트 인증서로 변경되었고 인증서 발급 기관은

2017년에 1024비트 인증서 발급을 중단할 예정입니다.

API 인증서 자격증명 서명에 사용되는 루트 CA 인증서를 사용할 수 있나요?

예. API 자격증명으로 발급된 인증서는 PayPal에서 서명합니다. 시스템에서 신뢰

유효성 검사를 위해 루트 CA 인증서를 요구할 경우 PayPal 담당자에게 문의하세요.

클래식 API에 대한 GET 메서드 사용중단

요약하면...

PayPal은 현재 익스프레스 체크아웃, Website Payments Pro, MassPay 및 버튼

관리자에 사용된 클래식 NVP/SOAP API에서 GET와 POST HTTP 메서드 사용을 모두

허용합니다. PayPal은 2016년 9월 30일부터 이러한 API에 대해 POST 요청 메서드

사용만 허용합니다. 이러한 변경 사항은 REST와 Adaptive API와 같은 다른 API 제품의

동작에 영향을 주지 않습니다.

서비스에 지장이 발생하지 않도록 이러한 변경에 시스템이 준비가 되어 있는지

2016년 9월 30일까지 확인해야 합니다.

API 인증서 갱신

Copyright ©2016 PayPal Inc. All rights reserved. 클래식 API에 대한 GET 메서드 사용중단 | 18

취해야 할 조치는 무엇인가요?

기술 세부정보

클래식 NVP/SOAP API 정보

대부분의 경우 PayPal의 클래식 API는 NVP(Name-Value Pair) 또는 SOAP(Simple Object

Access Protocol) 프로토콜을 사용하여 통합되고 PayPal의 api* 엔드포인트(예:

“api-3t.paypal.com”)를 사용합니다. 이러한 NVP/SOAP API는 익스프레스 체크아웃,

Website Payments Pro, MassPay, 버튼 관리자에 사용됩니다. 요청에 사용된 URL이

다음 조건과 일치하는지 보고 요청에서 NVP/SOAP API를 사용하고 있는지 구분할 수

있습니다.

요청에서 다음 엔드포인트 중 하나를 사용하나요?

o api.paypal.com

o api-aa.paypal.com

o api-3t.paypal.com

o api-aa-3t.paypal.com

NVP 기반 API의 경우:

현재 클래식 NVP/SOAP API를

사용하고 있나요?

(이러한 API에 대한 자세한 내용은

아래 기술 정보 참조)

예

클래식 NVP/SOAP API 요청에 GET

HTTP 요청 메서드를 사용하나요?

예

클래식 NVP/SOAP API를 요청할 때

항상 POST HTTP 요청 메서드를

사용하도록 코드를 업데이트하세요.

아니요

좋습니다! 조치가 필요하지 않습니다.

아니요

좋습니다! 조치가 필요하지 않습니다.

Copyright ©2016 PayPal Inc. All rights reserved. 클래식 API에 대한 GET 메서드 사용중단 | 19

o URL 구조가 *.paypal.com/nvp/인가요?

o 요청에 METHOD, USER 및 PWD 매개 변수가 있나요?

SOAP 기반 API의 경우:

o URL 구조가 *.paypal.com/2.0/인가요?

o 사용자 이름과 암호 요소가 있는 자격증명 요소를 갖춘 SOAP-ENV:Header가 포함되어

있나요?

전체 API 작업 목록을 포함한 자세한 내용은 아래 FAQ와 PayPal 개발자 포털의 NVP 및

SOAP API 참조 문서에서 확인하세요.

임시 Sandbox 엔드포인트 - 준비 완료

PayPal은 앞으로 Sandbox 및 프로덕션 엔드포인트가 따르게 될 최신 보안 표준을

바탕으로 새로운 임시 Sandbox 엔드포인트를 만들었습니다. 이러한 임시 엔드포인트를

사용하여 Sandbox 엔드포인트를 업데이트하기 전에 코드가 필수 표준을 충족하는지

확인할 수 있습니다.

test-api.sandbox.paypal.com

test-api-3t.sandbox.paypal.com

이러한 엔드포인트는 2016년 9월 30일까지 사용할 수 있습니다.

Sandbox 엔드포인트 - 2016년 6월 17일 이후 준비 완료

Sandbox 환경에서는 NVP/SOAP API 요청에 대해 POST 메서드 사용만 허용합니다.

api.sandbox.paypal.com

api-3t.sandbox.paypal.com

api-aa.sandbox.paypal.com

api-aa-3t.sandbox.paypal.com

프로덕션 엔드포인트 - 2016년 9월 30일 이후 준비 완료

프로덕션 환경에서는 클래식 NVP/SOAP API 요청에 대해 POST 메서드 사용만

허용합니다.

api.paypal.com

api-aa.paypal.com

api-3t.paypal.com

api-aa-3t.paypal.com

FAQ

GET와 POST HTTP 요청 메서드의 차이는 무엇인가요?

GET는 데이터 요청에 사용되지만 POST는 지정된 리소스로 데이터를 제출하는 데

사용됩니다. 보안 관점에서 주요 차이점은 GET 요청의 경우 URL에서 매개 변수를

전달하고 캐싱할 수 있다는 점입니다. 이 사이트에는 이러한 차이점에 대한

세부정보가 자세히 나와 있습니다.

PayPal REST API가 영향을 받지 않는 이유는 무엇인가요?

REST API는 API 설계의 일환으로 다양한 HTTP 요청 메서드를 사용합니다. GET

메서드는 개체에 대한 세부정보를 요청하는 데 사용됩니다. API 자격증명 정보는 HTTP

헤더로 전달되므로 GET 요청 캐싱과 관련된 위험이 줄어듭니다.

Copyright ©2016 PayPal Inc. All rights reserved. 클래식 API에 대한 GET 메서드 사용중단 | 20

이러한 변경 사항으로 인해 영향을 받는 특정 API 작업은 무엇인가요?

익스프레스 체크아웃 API 작업

AddressVerify

BAUpdate

BillOutstandingAmount

Callback

CreateBillingAgreement

CreateRecurringPaymentsProfile

DoAuthorization

DoCapture

DoExpressCheckoutPayment

DoReauthorization

DoReferenceTransaction

DoVoid

GetBalance

GetBillingAgreementCustomerDetails

GetExpressCheckoutDetails

GetPalDetails

GetRecurringPaymentsProfileDetails

GetTransactionDetails

ManageRecurringPaymentsProfileStatus

RefundTransaction

SetCustomerBillingAgreement

SetExpressCheckout

TransactionSearch

UpdateAuthorization

UpdateRecurringPaymentsProfile

대량 결제 API 작업

MassPay

Website Payments Pro API 작업

BillOutstandingAmount

CreateRecurringPaymentsProfile

DoCapture

DoDirectPayment

DoNonReferencedCredit

DoReauthorization

DoReferenceTransaction

DoVoid

GetBalance

GetRecurringPaymentsProfileDetails

GetTransactionDetails

ManagePendingTransactionStatus

ManageRecurringPaymentsProfileStatus

RefundTransaction

TransactionSearch

Copyright ©2016 PayPal Inc. All rights reserved. 클래식 API에 대한 GET 메서드 사용중단 | 21

UpdateAuthorization

UpdateRecurringPaymentsProfile

버튼 관리자 API 작업

BMButtonSearch

BMCreateButton

BMGetButtonDetails

BMGetInventory

BMManageButtonStatus

BMSetInventory

BMUpdateButton

Copyright ©2016 PayPal Inc. All rights reserved. 요약 | 1

기술 백서

내용

요약 ............................................................ 1

2016 업그레이드 이유 ............................................ 2

판매자 리소스 ................................................... 4

결론 ............................................................ 4

요약 금융 기술 선도업체인 PayPal의 사명은 간편하고 합리적이며,

안전하고 신뢰할 수 있는 금융 서비스와 디지털 결제를

제공하는 것입니다. 이러한 사명를 달성하기 위해 PayPal은

여러 조직 및 위원회의 권고사항과 기준을 고려하여 보안

상태를 지속적으로 평가하여 판매자와 고객이 신뢰할 수 있는 결제 경을

조성하고자 합니다.

최근 PCI 위원회가 2018년까지 최소 TLS 1.1 또는 가능한 TLS 1.2로

업그레이드하는 의무사항에 대해 시행 연기를 권장했지만, PayPal은 원래의

2016년 일정을 유지하기로 결정했습니다. 2016년 6월 17일 PayPal은 TLS 1.0

및 1.1에 대한 지원을 중단하는 절차를 시작할 것입니다. 즉, 모든 판매자가

PayPal과 API 커뮤니케이션을 할 때 TLS 1.2를 사용해야 합니다.

PayPal은 이러한 결정의 이유를 설명하고 업그레이드 지원에 사용할 수 있는

PayPal 리소스를 판매자에게 안내하기 위해 이 기술 백서를 작성했습니다.

PayPal의 2016년 6월 TLS 1.2

업그레이드에 대한 기초

Copyright ©2016 PayPal Inc. All rights reserved. 2016 업그레이드 이유 | 2

2016 업그레이드 이유

SHA-256 인증서의 2016년 업그레이드 날짜는 변경되지 않고 그대로

유지됩니다.

2014년에 주요 브라우저와 인증 기관 커뮤니티는 2016년

1월 1일부터 더 이상 SHA-1 인증서를 발급하지 않으며,

새로 발급한 모든 인증서가 SHA-256이라는 것을

발표했습니다. 2017년 1월 1일부터 기존의 SHA-1

인증서는 모두 '신뢰할 수 없는' 것으로 간주되며 관련 경보 메시지가

표시됩니다.

2009년 이전에 통합한 판매자는 이러한 새로운 SHA-256 인증서를 지원하려면

해당 운영 체제 또는 SSL 스택 및 주요 스토어를 업그레이드해야 합니다.

판매자는 TLS 1.2 및 G5 루트 인증서로 업그레이드하면 SHA-256 지원이

보장됩니다. 이와는 달리 TLS 1.0과 1.1 배치에는 추가 업그레이드와

필요하고 비용이 발생할 수 있습니다.

판매자가 SHA-256 인증서로 업그레이드하는 경우 대부분 이미 TLS 1.2를

사용할 수 있으므로 TLS 1.2만 사용하도록 설정하는 작업은 최소가 됩니다.

SHA-256 인증서와 TLS 1.2를 동시에 지원하도록 업그레이드하는 것이 이러한

작업을 모두 수행하기 위한 가장 효율적이며 안전한 방법입니다.

SSL 및 TLS 위협과 차단 노력은 계속 진화하고 있습니다.

SSL 및 TLS 프로토콜은 새로운 위협이 발생함에 따라 진화해 왔습니다.

2011년 이래로 SSL 3.0 및 TLS 1.0과 1.1에 대한 세 차례의 주요 공격 과 몇

번의 사용 중단 문제로 기업들이 수백만 달러의 손해를 입었습니다. TLS 이전

버전이 위험하므로 PayPal은 이로 인한 영향을 최소화하기 위해 가장 안전한

대안을 선택하고자 합니다. TLS 1.2만 허용할 경우 PayPal이나 판매자가 이전

버전의 취약성으로 인해 피해를 보는 상황을 방지할 수 있습니다. 현재 TLS

1.2는 커뮤니케이션 채널 보호에 있어서 최상의 보안 기능을 제공합니다.

긴급 업그레이드를 방지하는 것이 판매자, 소비자 및 PayPal에게

이롭습니다.

2014년 10월 POODLE 공격으로 인해 전례 없는 PCI 위원회의 조치가 이루어져

SSL 3.0의 사용을 극도로 위험으로 격상하고 두 달 동안 촉박하게 TLS

1.0으로 업그레이드해야 했습니다. TLS 1.0과 1.1의 여러 측면에 대한 업계의

평가(예: 급격하게 증가하는 SHA-1의 취약성)에 따르면 이후 이 버전 중

하나에 대한 공격이 일어날 경우 또 다시 긴급 업그레이드를 해야 하는

상황이 발생할 수 있습니다. 따라서 PayPal이 제시한 6월 기한까지 조치를

취하면 판매자는 급작스런 결정을 내려야 하는 상황을 피할 수 있습니다.

Copyright ©2016 PayPal Inc. All rights reserved. 2016 업그레이드 이유 | 3

TLS 1.2 업그레이드는 2016년 판매자 로드맵에 이미 있습니다.

PCI 위원회는 원래 2015년 4월에 2016년 TLS 1.2 업그레이드 의무화를

발표하고, 2015년 12월에 연장을 발표했습니다. 연장이 발표될 무렵 대부분의

판매자는 원래 날짜의 2016년 로드맵을 보유하고 있었습니다. 2016년 날짜를

유지하면 PayPal과 판매자가 원래 로드맵을 계속해서 유지하고 비즈니스

보안을 강화할 수 있습니다. 이 방법이 가장 현대적인 시스템 구성이며 현재

기존의 모든 옵션 중에서 가장 수명이 긴 방안입니다.

TLS 1.2만 허용하는 것에 대해 많은 기업이 동의하고 있습니다.

기술 산업 분야의 여러 회사에서는 TLS 1.2만 허용하는 것이 인터넷

커뮤니티에 가장 안전하다고 판단하고 있습니다. Apple의 ATS(Application

Transport Security)는 데스크톱과 모바일 플랫폼에 대해 TLS 1.2 연결을

의무화했습니다 . iOS 9용으로 개발된 새로운 애플리케이션은 TLS 1.2만

사용하거나 예외처리를 해야 합니다. Apple이 모바일 트래픽의 거의 60%를

차지한다는 점을 고려할 때 이 결정은 인터넷 사용자 대다수에게 영향을

줍니다.

PayPal 및 Apple과 동일한 취지에서 CloudFlare도 TLS 1.2만 연결하는 것을

의무화하도록 결정했습니다. CloudFlare는 사이트 방문자와 웹 서버 간에

프록시 역할을 함으로써 웹 사이트 트래픽을 가속화하고 보호합니다.

관리되는 DNS 트래픽의 35%를 차지하므로 이 결정은 중소기업 사이트

트래픽의 상당 부분에 영향을 미칩니다.

이러한 기업들의 결정과, 보안 연구업체, 블로거, SSL Labs와 같은 회사의

주요 입장을 종합해 볼 때 TLS 1.2만 허용하는 것이 PayPal 및 판매자를 위한

바람직한 결정이라는 점이 더욱 명확해집니다.

PCI 및 NIST 권장 사항에 따르면 TLS 1.2가 이전 버전보다 우수합니다.

PCI가 TLS 1.1을 명시적으로 금지하지는 않지만 대부분의 PCI 설명서와 NIST

권장 사항은 TLS 1.2로 이동할 것을 주창하고 있습니다.

[Council] , 2페이지에서 SSL과 초기 TLS는 공용 또는 신뢰할 수 없는 커뮤니케이션 채널에서

결제 데이터를 보호하기 위해 강력한 암호화를 구현할 보안 필요성을 더 이상 충족하지

않습니다.

[Council], 2페이지에서 PCI 보안 표준 위원회는 “/.../ 법인에 TLS v1.2를 고려하도록

강력히 촉구했지만 적어도 발행 시 최소 기준인 TLS v1.1”의 현대 암호화 프로토콜로 이전할

것을 권장합니다. 같은 페이지에 또한 다음과 같이 언급되어 있습니다. “모든 TLS v1.1

구현이 안전하다고 간주되는 것은 아닙니다. 안전한 TLS 구성에 대한 지침은 NIST SP 800-52

rev 1을 참조하세요.“

[Thomas]에서 (비공식) PCI 규정 준수 안내서에는 PCI DSS 3.1이 다음과 같이 요약되어

있습니다. “이러한 진화하는 요건은 SSL과 초기 TLS(버전 1.0 및 1.1을 제거할 것을

권장합니다.)”.

NIST는 서버와 클라이언트 모두 TLS 1.2로 이동할 것을 권장합니다. 예를 들면, [NIST]에서

“승인된 체계와 알고리즘을 사용하는 암호 그룹”의 TLS 1.1은 최소한의 필요 요건으로

간주되지만, 권장 사항은 “/.../ 2015년 1월 1일까지 에이전시가 승인된 체계와 알고리즘을

사용하여 구성된 TLS 1.2에 대한 마이그레이션 계획을 개발하는 것입니다”.

Copyright ©2016 PayPal Inc. All rights reserved. 판매자 리소스 | 4

판매자 리소스 PayPal과 판매자 간에 커뮤니케이션 라인을 유지하기 위해

이러한 프로세스에 대한 최신 정보를 게시할 TLS 1.2

업그레이드 마이크로사이트를 만들었습니다.

판매자는 마이크로사이트 외에 계정 담당자나 지원 센터를

통해 PayPal에 문의할 수 있습니다.

결론 원래 업그레이드 일정대로 진행함으로써 PayPal 판매자와

판매자의 데이터 및 고객의 보안이 더욱 강화된다는 점을

다시 한 번 강조해서 말씀드립니다. PCI 위원회가 올바른

방향으로 업계를 유도하고 있으나, 이보다 앞서 PayPal이

업그레이드하는 이유는 판매자, 고객, 회사의 보안을 위해 최선의 조치를

취하고, 또한 2016년 12월 31일까지 SHA-256 인증서로 업그레이드하는 인증

기관과 브라우저 업계의 의무사항도 충족하기 위한 것입니다. 사기 및 금융

데이터 도난의 위협을 최소화하는 것은 PayPal의 핵심 비즈니스 방침이며,

PayPal이 전세계에서 가장 신뢰할 수 있는 결제 플랫폼 중 하나로 인정받는

이유이기도 합니다.

SSL 3.0: Secure Sockets Layer 3.0은 TLS의 전신으로, 1990년대에 웹에서 데이터를 안전하게 전송하기 위해

설계되었습니다. 최근에는 대부분의 브라우저/사용자가 더 이상 SSL을 사용하지 않지만, 브라우저가 오래된 경우 SSL

3.0이 기본으로 다시 사용될 수 있습니다. PayPal을 포함한 대부분의 기업에서는 2014 POODLE 공격이 발생할 때까지 SSL

3.0을 계속 지원했었습니다. 그러나 SL 3.0 지원은 곧 중단되었습니다.

TLS: Transport Layer Security는 현재 웹을 통한 커뮤니케이션 보안의 표준입니다. TLS는 1999년에 설계되었으며,

2006, 2008 및 2011년 업데이트로 TLS 1.0, 1.1, 1.2, 및 1.3이 만들어졌습니다. 이러한 설명을 위해 TLS 1.0 및 1.1

지원 중단에 대해 언급하겠습니다. 이 중단은 부분적으로 2015년 PCI DSS 3.1(결제 카드 산업 데이터 보안 표준)의 변경

때문입니다. 자세한 내용은 Transport Layer Security를 참조하세요.

SSL/TSL 공격: 다음 공격 및 사용 중단은 2011년 이후 발생했습니다.

2011: 비스트. 비스트는 HTTPS로 보호된 세션 쿠키의 MITM(man-in-the-middle, 메시지 가로채기) 암호 해독 및 CBC

블록 암호와 TLS 1.0의 취약성을 드러낸 SSL/TLS 암호화에 대한 공격입니다. 이 공격으로 말미암아 향상된 보안을 위해

TLS 1.1과 1.2의 사용이 촉진되는 한편 CBC 사용은 중단되고 RC4 스트림 암호화를 사용하게 되었습니다.

2013: Crime. CRIME(Compression Ratio Info-leak Made Easy)은 데이터 압축도 사용하는 HTTPS 및 SPDY 프로토콜을

사용하여 연결에 보안 웹 쿠키를 악용한 클라이언트 측 공격입니다. TLS 1.2 프로토콜에서 압축 안함 기능을 구현하여

이 공격을 완화할 수 있습니다.

2014: POODLE. POODLE(Padding Oracle On Downgraded Legacy Encryption)은 이전 클라이언트와 오래된 브라우저가 TLS

1.0 및 1.1에서 SSL 3.0으로 대체되는 경향을 악용하는 MITM 공격입니다. 이러한 취약성으로 인해 PayPal을 포함한

대부분의 대기업이 SSL 3.0 지원을 중단하기로 결정했습니다. TLS 1.0 이상이 지원 표준이 되었습니다.

2013-2015: RC4. 2011년에 브라우저만으로는 공격을 방지할 수 없었기 때문에 RC4가 Beast를 완화하는 스트림

암호화였습니다. 2013년까지 RC4의 약점이 발견되었고 이 때가 되자 브라우저가 Beast와 같은 공격으로부터 보호할 수

있게 되었습니다. 2015년까지 IETF는 중요한 보안 약점을 언급하면서 RC4의 사용 중단을 선언했습니다. 이 사례는

끊임없이 진화하는 보안 환경과 안전한 것으로 간주되는 상태를 계속해서 평가해야 하는 필요성을 보여주므로

중요합니다.

Copyright ©2016 PayPal Inc. All rights reserved. 결론 | 5

Apple의 App Transport Security: “ATS(App Transport Security)는 앱과 해당 백엔드 간의 보안 연결에서 모범

사례를 적용합니다. ATS는 예기치 않은 노출을 방지하고, 안전한 기본 동작을 제공하며, 쉽게 채택할 수 있으며.

기본적으로 iOS 9 및 OS X v10.11에 있습니다. 새 앱을 만드는지 아니면 기존 앱을 업데이트하는지에 관계없이 가능한

빨리 ATS를 채택해야 합니다. 새 앱을 개발 중인 경우 HTTPS만 사용해야 합니다. 기존 앱이 있는 경우 현재 가능한 만큼

HTTPS를 사용해야 하고, 나머지도 최대한 빨리 이동할 계획을 세워야 합니다. 또한 상위 수준의 API를 통한

커뮤니케이션은 전달 보안에 TLS 버전 1.2를 사용하여 암호화해야 합니다. 이 요건을 따르지 않는 연결을 시도하는 경우

오류가 발생합니다. 앱에서 비보안 도메인에 요청해야 하는 경우 앱의 Info.plist 파일에 이 도메인을 지정해야

합니다.”

[Council] PCI 보안 표준. “SSL에서 마이그레이션 및 초기 TLS.” 2015년 4월. PCI 보안 표준

[Thomas] Tim. “PCI DSS 3.1 둘러보기.” 2015년 4월 22일 PCI 규정 준수 안내서