From ec31cb8857a524f6eb9fb596b1b7aac5e4332c07 Mon Sep 17 00:00:00 2001 From: Hyeon Kim Date: Tue, 26 Mar 2024 00:41:16 +0900 Subject: [PATCH] src/content: Overhaul contents --- .../java6-java-security-edit.astro | 27 +- src/content/docs/ko/tip/tls-support.mdx | 290 +++++++++--------- 2 files changed, 167 insertions(+), 150 deletions(-) diff --git a/src/content/docs/ko/tip/_components/tls-support/java6-java-security-edit.astro b/src/content/docs/ko/tip/_components/tls-support/java6-java-security-edit.astro index ee009517e..36b7dfc5c 100644 --- a/src/content/docs/ko/tip/_components/tls-support/java6-java-security-edit.astro +++ b/src/content/docs/ko/tip/_components/tls-support/java6-java-security-edit.astro @@ -1,10 +1,23 @@ -
-#Before
-security.provider.1=sun.security.provider.Sun security.provider.2=sun.security.rsa.SunRsaSign
-security.provider.3=com.sun.net.ssl.internal.ssl.Provider security.provider.4=com.sun.crypto.provider.SunJCE
-security.provider.5=sun.security.jgss.SunProvider security.provider.6=com.sun.security.sasl.Provider
-security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI security.provider.8=sun.security.smartcardio.SunPCSC
-#After
+
+# before
+security.provider.1=sun.security.provider.Sun
+security.provider.2=sun.security.rsa.SunRsaSign
+security.provider.3=com.sun.net.ssl.internal.ssl.Provider
+security.provider.4=com.sun.crypto.provider.SunJCE
+security.provider.5=sun.security.jgss.SunProvider
+security.provider.6=com.sun.security.sasl.Provider
+security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI
+security.provider.8=sun.security.smartcardio.SunPCSC
+
+# after
 # Add provider with higher priority
 security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
 security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider
diff --git a/src/content/docs/ko/tip/tls-support.mdx b/src/content/docs/ko/tip/tls-support.mdx
index b53c986e6..f78aa542e 100644
--- a/src/content/docs/ko/tip/tls-support.mdx
+++ b/src/content/docs/ko/tip/tls-support.mdx
@@ -1,6 +1,6 @@
 ---
 title: TLS 지원 범위
-description: 포트원 API의 TLS 지원 범위 및 설정 가이드를 확인할 수 있습니다.
+description: 포트원 v1 API의 TLS 지원 범위 및 설정 가이드를 확인할 수 있습니다.
 ---
 
 import "./_assets/tls_support/tls-support-styles.css";
@@ -12,13 +12,13 @@ import javaTLSSupportTable from "./_assets/tls_support/TLS_support_for_java.png"
 import Java6JavaSecurityEdit from "./_components/tls-support/java6-java-security-edit.astro";
 
 2024년 9월 1일부터 포트원을 이용하는 고객님들의 개인정보 및 결제정보를 더욱 안전하게 보호하기 위해
-API 서버(api.iamport.kr)의 프로토콜 및 Cipher Suite 지원 범위가 변경됩니다.
+v1 API 서버(api.iamport.kr)의 TLS 버전 및 Cipher Suite 지원 범위가 변경됩니다.
 
 ## 변경사항 요약
 
 - HTTP 평문 통신에 대한 지원이 중단됩니다.
 - TLS 1.0, 1.1 버전에 대한 지원이 중단됩니다.
-- 특정 조건을 만족하지 않는 Legacy Cipher Suite에 대한 지원이 중단됩니다.
+- 보안성이 떨어지는 일부 Legacy Cipher Suite 들에 대한 지원이 중단됩니다.
 
 
@@ -89,96 +89,122 @@ API 서버(api.iamport.kr)의 프로토콜 및 Cipher Suite 지원 범위가 변
 
 

   

-    HTTP 평문 통신 지원 중단
+    HTTP 평문 통신 지원을 중단하는 이유
   

 
-  TLS를 이용하지 않는 HTTP 통신의 경우 데이터를 암호화하지 않고 평문 상태로 전송하기 때문에 보안에 취약합니다.
-  암호화/복호화 등과 무관하게 중간자가 통신 중간에서 데이터를 가로챈다면 데이터의 내용을 볼 수 있고 악의적으로 이용할 수 있습니다.
-  또한, HTTP 통신은 기본적으로 인증서를 이용한 인증 절차를 거치지 않기 때문에 다양한 방법으로 데이터를 갈취할 수 있습니다.
-  따라서 DNS 캐시 포이즈닝(DNS 캐시에 악성 침입하여 잘못된 응답을 반환하여 사용자가 잘못된 웹사이트에 연결되도록 하는 행위)이나 하이재킹(다른 도메인의 네임서버나 IP로 리디렉션하는 행위),
-  중간자 공격(Man in the middle attack, MITM, 두 서버 사이에서 데이터를 도청하는 행위)에 매우 취약하기 때문에 HTTP 평문 통신에 대한 지원을 중단합니다.
+  TLS를 이용하지 않는 평문 HTTP 통신은 데이터를 암호화하지 않고 평문 상태로 전송하기 때문에 다양한
+  종류의 공격에 몹시 취약합니다. 먼저 별도의 암호화가 없기 때문에 모든 종류의 [도청]과 [스니핑
+  공격]에 의해 API 키나 민감한 고객정보가 공격자에게 쉽게 노출될 수 있습니다. 뿐만 아니라 [DNS
+  spoofing]이나 [ARP spoofing]과 같은 [Active MITM 공격][MITM]을 통해 공격자가 결제 API 요청이나
+  응답을 변조하는 것까지도 가능하기 때문에, 정보 유출뿐 아니라 결제금액을 위조하거나 결제상품,
+  결제사용자를 바꿔치기하는 유형의 공격도 가능합니다.
+
+  따라서 암호화되지 않은 평문 HTTP 통신을 실제 운영환경에서 사용하여선 절대 안 됩니다. 포트원 v1
+  API를 평문 HTTP 통신으로 호출하고 계시는 고객님께선 즉시 API endpoint를 http://api.iamport.kr 에서
+  https://api.iamport.kr 로 바꿔주셔서, TLS를 활성화시켜주셔야만 합니다.
+
+  [도청]: https://en.wikipedia.org/wiki/Network_eavesdropping
+  [스니핑 공격]: https://en.wikipedia.org/wiki/Sniffing_attack
+  [DNS spoofing]: https://en.wikipedia.org/wiki/DNS_spoofing
+  [ARP spoofing]: https://en.wikipedia.org/wiki/ARP_spoofing
+  [MITM]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
 

   

-    TLS 1.0, 1.1 지원 중단
+    TLS 1.0, 1.1 지원을 중단하는 이유
   

 
-  TLS 1.0과 1.1은 각각 1999년, 2006년에 공개된 보안 표준으로 POODLE(Padding Oracle On Downgraded Legacy Encryption)이나
-  BEAST(Browser Exploit Against SSL/TLS)와 같은 여러 공격에 취약합니다.
-  2021년 3월 국제 인터넷 표준화 기구인 IETF에서 발표한 RFC 8996에 따르면 TLS 1.0 및 1.1을 deprecate에 대해 명시되어 있고,
-  AWS, Google, Apple, Microsoft 등 많은 국제 기업들이 자사 제품 및 API 이용 시 TLS 1.2 미만 버전에 대한 이용 제한을 두고 있습니다.
-  TLS 1.0 및 1.1을 사용함에 따라 발생할 수 있는 문제 및 취약점은 다음과 같습니다.
-
-  ### BEAST (Browser Exploit Against SSL/TLS) 공격
-
-  TLS 1.1 미만 버전에서 발생할 수 있는 BEAST 공격은 중간자 공격으로 시작됩니다.
-  TLS 1.0(그리고 더 낮은 수준의 프로토콜)은 CBC(Cipher Block Chaining) 방식으로 데이터들을 암호화하고, 암호화 강도를 높이기 위해 IV(Initial Vector)를 사용합니다.
-  하지만 IV는 이전 블록의 암호화 결과로 중간자 공격을 통해 데이터가 노출되는 경우 유추가 가능합니다.
-  블록 암호화의 경우 암호화된 데이터의 길이가 고정되어 있고, 공격자가 알아야 할 정보(ex. 인증 세션 값)를 제외한 정보는 얼마든지 유추할 수 있기 때문에
-  (ex. host, encoding이나 charset 관련 헤더) 공격자가 계산해야 할 경우의 수가 매우 줄어듭니다.
-  이러한 문제점은 TLS 1.1에서 IV를 유추할 수 없도록 수정하면서 해결되었습니다.
-
-  ### 취약한 암호화 알고리즘 사용
-
-  TLS 1.0 및 1.1은 handshake protocol에서 사용하는 finished message를 구성하거나 pseudorandom function(PRF)에서 해시를 만들 때 등
-  암호화 해시 함수가 필요한 경우 MD5와 SHA-1에 의존하고 있습니다.
-  문제는 두 해시 함수 모두 해시 충돌(다른 입력값으로 같은 해시를 생성)에 취약할뿐더러
-  컴퓨팅 자원의 발전으로 인해 같은 해시를 생성하는 입력값 계산에 드는 시간이 점점 줄어들고 있다는 것입니다.
-  이러한 문제는 TLS 1.2에서 해시 함수를 MD5와 SHA-1으로 고정하는 것이 아닌
-  Cipher Suite에 명시되어있는 MAC(Message authentication code) 알고리즘을 사용하도록 하면서 해결되었습니다.
-  뿐만 아니라 TLS 1.2부터는 데이터 블록 암호화 운용 시 GCM(Galois/Counter Mode)같은 AEAD(Authenticated encryption)을 허용하는 등 더 높은 수준의 보안을 지원합니다.
-
-  ### POODLE (The Padding Oracle On Downgraded Legacy Encryption) 공격
-
-  POODLE 공격 역시 BEAST와 같이 중간자 공격으로 시작됩니다.
-  공격자가 의도적으로 클라이언트와 서버 사이의 연결을 반복적으로 drop시키거나 잘못된 메시지를 전송하는 경우
-  서버는 클라이언트와의 통신 프로토콜이 맞지 않는 것으로 간주하여 더 낮은 버전의 프로토콜로 fallback 시킵니다.
-  SSL 3.0까지 버전이 내려간 이후에는 SSL 3.0의 블록 암호 패딩 검증에서의 허점을 이용합니다.
-  SSL 3.0에서는 패딩 값에 대한 검증을 하지 않고 패딩 길이에 대해서만 검증합니다.
-  공격자는 데이터 조작 시 서버의 응답을 통해 패딩(길이) 검증에 실패하였는지 MAC 검증에 실패하였는지 구분이 가능하기에
-  패딩 값은 임의로 유지한 채 길이만을 조절해가면서 반복적으로 요청을 보내는 방식으로
-  암호화 블록에서 패딩을 제외한 실제 데이터의 길이 밎 값을 도출해낼 수 있습니다.
-  TLS 1.2 이하의 프로토콜을 사용하는 웹서버에서는 낮은 버전의 프로토콜로 fallback되지 않도록 허용 프로토콜을 제한하여 해결할 수 있지만
-  TLS 1.3부터는 근본적인 원인인 중간자 공격을 막음으로써 POODLE 공격을 방어합니다.
+  TLS 1.0과 1.1은 각각 1999년, 2006년에 공개된 보안 표준으로, [POODLE]이나 [BEAST]와 같은 널리
+  알려진 여러 공격들에 취약합니다. 국제 인터넷 표준화 기구인 IETF는 2021-03-23 [RFC 8996]를 통해
+  TLS 1.0과 1.1을 deprecate 시켰으며, AWS, Google[^tls-1.0-chrome], Apple, Microsoft 등 많은 국제 기업들이 자사 제품
+  및 API 이용 시 TLS 1.2 미만 버전에 대해 제한을 두고 있습니다.[^tls-1.0-browsers] TLS 1.0 및 1.1에 존재하는 문제
+  및 취약점들은 아래와 같습니다.
+
+  [POODLE]: https://en.wikipedia.org/wiki/POODLE
+  [BEAST]: https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack
+  [RFC 8996]: https://www.rfc-editor.org/rfc/rfc8996.html
+  [^tls-1.0-chrome]: ["TLS 1.0 and TLS 1.1 - Chrome Platform Status"](https://chromestatus.com/feature/5759116003770368). chromestatus.com. Retrieved 2024-03-25.
+  [^tls-1.0-browsers]: Bright, Peter (2018-10-17). ["Apple, Google, Microsoft, and Mozilla come together to end TLS 1.0"](https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/). Retrieved 2024-03-25.
+
+  ### [BEAST] (Browser Exploit Against SSL/TLS) 공격
+
+  [BEAST] 공격은 [중간자 공격][MITM]을 동반하는 공격으로, TLS 1.1 미만 버전에 적용 가능합니다.
+
+  1.1 버전 미만의 TLS는 [스트림 암호] 대신 [블록 암호]를 사용할경우, [Mode of operation]으로 무조건
+  [CBC]를 사용해야만 했습니다. [CBC] 모드는 예측 가능한 [IV]를 사용할 경우 Chosen-plaintext attack에
+  취약해진다는 문제를 갖고있는데, TLS 1.0은 이후 버전들과는 다르게 항상 이전 블록의 암호화 결과를
+  사용하도록 만들어져있어, IV의 예측이 가능했고, HTTP는 특성상 헤더 부분의 정보 엔트로피가 낮아
+  공격자가 높은 확률로 암호문을 복호화하는데에 성공할 수 있었습니다.
+
+  [0/n split, 1/n-1 split]과 같은 취약점 우회수단이 몇가지 존재하나 이는 클라이언트측에서만 적용할 수
+  있는 우회수단이고, TLS 1.0을 사용하면서 서버측에서 BEAST 취약점을 우회하려면 [블록 암호] 자체를
+  사용하지 않아야 합니다. 문제는 TLS 1.0에서 블록 암호를 비활성화할 경우 사용할 수 있는 남은 유일한
+  암호화 수단은 더더욱 취약한것으로 알려진 [RC4] 뿐이기 때문에, 결론적으로 TLS 1.0은 사용하지 않아야
+  합니다.
+
+  TLS 1.2는 AES [GCM]과 같은 [AEAD] 지원, [ChaCha20]과 같은 안전한 [스트림 암호] 지원을 통해 이
+  문제를 해결하였습니다.
+
+  [스트림 암호]: https://en.wikipedia.org/wiki/Stream_cipher
+  [블록 암호]: https://en.wikipedia.org/wiki/Block_cipher
+  [Mode of operation]: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
+  [CBC]: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_block_chaining_(CBC)
+  [IV]: https://en.wikipedia.org/wiki/Initialization_vector
+  [0/n split, 1/n-1 split]: https://www.cryptologie.net/article/378/1n-1-split-to-circumvent-beast/
+  [RC4]: https://en.wikipedia.org/wiki/RC4
+  [GCM]: https://en.wikipedia.org/wiki/Galois/Counter_Mode
+  [AEAD]: https://en.wikipedia.org/wiki/Authenticated_encryption
+  [ChaCha20]: https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant
+
+  ### 약한 해시 함수 사용
+
+  TLS 1.2 이후 버전과는 달리, TLS 1.0과 1.1은 [cryptographic hash function]이 필요한 곳에 무조건
+  [MD5]나 [SHA-1]과 같이 오래되고 약한 해시함수를 쓰도록 정해져있습니다. [MD5], [SHA-1] 모두 지금은
+  상당히 낮은 비용의 [chosen-prefix collision attack]이 발견되어서[^sha-1-collision], [HMAC] 이외의
+  용도로는 사용하지 말아야합니다. 따라서 TLS 1.2 미만 버전은 사용하지 않아야합니다.
+
+  [cryptographic hash function]: https://en.wikipedia.org/wiki/Cryptographic_hash_function
+  [MD5]: https://en.wikipedia.org/wiki/MD5
+  [SHA-1]: https://en.wikipedia.org/wiki/SHA-1
+  [chosen-prefix collision attack]: https://en.wikipedia.org/wiki/Collision_attack#Chosen-prefix_collision_attack
+  [HMAC]: https://en.wikipedia.org/wiki/HMAC
+
+  [^sha-1-collision]: Gaëtan Leurent; Thomas Peyrin (2020-01-05). ["SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust"](https://eprint.iacr.org/2020/014.pdf) (PDF).
 

   

-    특정 조건을 만족하지 않는 Legacy Cipher Suite에 대한 지원 중단
+    일부 Legacy Cipher Suite 들에 대한 지원을 중단하는 이유
   

 
-  Cipher Suite란 TLS 통신시 사용되는 암호 알고리즘의 집합을 의미합니다.
-  포트원에서는 기존에 지원하던 Cipher Suite 중 일부 집합에 대한 지원을 중단하며 이는 다음과 같은 기준을 충족하지 않는 집합에 해당합니다.
+  Cipher Suite란 TLS 통신시 사용되는 암호 알고리즘의 집합을 의미합니다. TLS 1.2는 다양한 Cipher
+  Suite들을 지원하지만 이들 모두가 안전한것은 아닙니다. 포트원은 아래 기준을 모두 충족하는 안전한
+  Cipher Suite들만을 지원하도록 정책을 변경하였습니다.
 
-  - Forward Secrecy(순방향 비밀성) 지원
-  - SHA-1 해시 함수 미사용
+  - [완전 순방향 비밀성(Perfect Forward Secrecy)][PFS]을 보장할 것
 
-  각 기준에 대한 설명은 다음과 같습니다.
+    TLS 통신 중 잠재적으로 발생할 수 있는 위험 요소 중 하나는, 키교환 알고리즘에 의해 생성된
+    세션키가 유출되었을 때 해당 세션키의 수명이 일시적이지 않다면 과거 세션에서 주고받았던
+    데이터들까지 모두 해독될 수 있다는 것입니다. [완전 순방향 비밀성][PFS]을 보장한다는 것은 매
+    세션마다 새로운 키를 생성함으로써 키가 유출되더라도 과거의 통신이 해독되는것을 막는것입니다.
+    완전 순방향 비밀성이 보장될 경우, TLS 프로토콜에 새로운 취약점이 발견되어 통신이 복호화당하는
+    사태가 발생하더라도, 공격자에게 노출하는 기밀의 범위를 크게 줄일 수 있습니다.
 
-  ### Forward Secrecy(순방향 비밀성) 지원
+  - [MD5], [SHA-1] 등 약한 해시 함수를 쓰지 않을 것
 
-  TLS 통신 중 잠재적으로 발생할 수 있는 위험 요소 중 하나는 키교환 알고리즘에 의해 생성된 세션키가 유출되었을 때
-  해당 세션키의 수명이 일시적이지 않다면 과거 세션에서 주고받았던 데이터들까지 해독될 수 있다는 것입니다.
-  Forward Secrecy를 지원한다는 것은 이와 같은 문제점을 보완하기 위해 매 세션마다 새로운 키를 생성함으로써
-  세션키가 유출되더라도 해당 세션을 제외한 다른 세션에는 영향을 미치지 않는 다는 것을 의미합니다.
+  - [RC4], 3DES 등 약한 암호화 알고리즘을 사용하지 않을 것, 국제표준 암호화 알고리즘만을 사용할 것
 
-  ### SHA-1 해시 함수 미사용
-
-  SHA-1에 대한 문제점은 위 _취약한 알고리즘 사용_ 관련 내용에서 설명한 바 있습니다.
-  미국 국립표준기술연구소(National Institute of Standards and Technology, NIST)에서는
-  2011년 SHA-1을 deprecate시킴과 동시에 2030년까지는 모두 대체되어야 한다고 발표하였으며
-  이에 따라 Google, Microsoft 등의 기업들에서 자신들의 제품에 대해 SHA-1 사용 및 지원을 중단한다 선언하였습니다.
+  [PFS]: https://en.wikipedia.org/wiki/Forward_secrecy
 

 
+ 
+
 ---
 
-## TLS 버전 및 Cipher Suite 업그레이드에 대한 가이드
+## TLS 버전 및 Cipher Suite 업그레이드 가이드
 
-지원 중단 예정인 TLS 버전 및 Cipher Suite를 사용하는 것으로 확인된 언어 및 버전에 대해
-TLS 버전 업 및 Cipher Suite 업그레이드에 대한 가이드를 제공합니다.
-포트원에서는 사용 가능 Cipher Suite에 대해서도 일부에 대해서만 사용이 가능한 TLS 1.2보다
-모든 Cipher Suite에 대해 사용이 가능한 TLS 1.3으로의 업그레이드를 권장합니다.
+포트원은 TLS 1.3 으로의 업그레이드를 권장합니다.
 
 ### Java 6
 
@@ -186,58 +212,57 @@ Java 6은 기본적으로 TLS 1.2를 지원하지 않습니다.
 
 

 
-JDK 6u121 버전부터는 TLS 1.2를 지원하지만 default TLS 버전은 여전히 1.0일뿐더러
-Java 6의 JCE(Java Cryptography Extension) Provider가 타원곡선 암호화 알고리즘을 지원하지 않기때문에
-단순 JDK 버전 컨트롤만으로는 지원 중단되는 Cipher Suite 퇴역이 불가능합니다.
-이에 따라 Java 6에서 포트원 통신 규격을 만족하도록 만들 수 있는 방법 2가지를 설명합니다.
+JDK 6u121 버전부터는 TLS 1.2를 지원하지만 default TLS 버전은 여전히 1.0일뿐더러 Java 6의 JCE(Java
+Cryptography Extension) Provider가 타원곡선 암호화 알고리즘을 지원하지 않기때문에 [완전 순방향
+비밀성][PFS]이 보장되지 않아 여전히 Legacy Cipher Suite를 써야합니다.
+
+따라서, Java 6에서 TLS 통신을 안전하게 하려면 아래 두 방법 중 하나를 택해야 합니다.
 
 

   

-    Java 8 이상으로 버전 업그레이드
+    JDK 8u261 이상으로 버전 업그레이드
   

 
-  가장 바람직한 방법은 공식 지원기간이 이미 종료된 Java 6에서 상위 버전으로 업그레이드하는 것입니다.
-  2023년 9월에 출시된 Java 21(LTS)로 업그레이드하는 것이 가장 바람직한 방법이지만 Java 6에서 한번에 높은 버전으로 점프하는 것은 체크해야할 side effect가 매우 많습니다.
-  반대로 바로 윗 버전인 Java 7의 경우 TLS 1.2를 지원하긴 하나 default TLS 버전은 1.0이기에 system property 혹은 코드 수정이 동반되어야 합니다.
-  또한 Java 7 역시 Java 6과 같이 지원이 중단되었기에 Java 7로의 업그레이드는 권장하지 않습니다.
-  제일 side effect가 적으면서 합리적인 방법은 Java 8(LTS)로 업그레이드하는 것으로,
-  Java 8의 경우 default TLS 버전이 1.2이며 JDK 8u261 이상부터는 TLS 1.3 통신을 지원하기 때문에 조건에 충족합니다.
+  가장 바람직한 방법은 공식 지원이 이미 종료된 Java 6의 사용을 멈추고, Java 8 이상의 버전으로
+  업그레이드하는 것입니다. Java 8 부터 기본 TLS 버전이 1.2이고, JDK 8u261 이상부터는 TLS 1.3 통신을
+  지원하기때문에 TLS 통신을 안전하게 할 수 있습니다.
+
+  Java 7의 경우, Java 6과 마찬가지로 보안 업데이트가 중단된 상태이고 기본으로 TLS 1.0을 사용하기
+  때문에 Java 7로의 업그레이드는 권장하지 않습니다.
 

 
 

   

-    외부 라이브러리를 이용한 구현체 강제 주입
+    서드파티 라이브러리를 통한 TLS 버전 업데이트
   

 
-  TLS 1.2 통신 및 ECC(타원곡선 암호화) 알고리즘을 사용하는 Cipher Suite 지원에 필요한
-  JCE(Java Cryptography Extension) 및 JSSE(Java Secure Socket Extension) 구현체를 외부 라이브러리의 것으로 이용하는 방법입니다.
-  본 가이드에서는 `Bouncy Castle`이라는 오픈소스 라이브러리를 이용한 예시를 설명합니다.
+  자바 업그레이드가 곤란할 경우, 서드파티 라이브러리를 사용해 TLS 버전을 업그레이드할 수 있습니다.
 
-  1. [https://www.bouncycastle.org/latest\_releases.html](https://www.bouncycastle.org/latest_releases.html)에 접속하여
+  TLS 1.2 및 [완전 순방향 비밀성][PFS]를 지원하는 서드파티 JCE(Java Cryptography Extension) 및
+  JSSE(Java Secure Socket Extension) 구현체를 설치할 경우, 자바 업그레이드 없이 TLS 통신을 안전하게
+  할 수 있습니다.
 
-     - `bcprov-jdk15to18-{LATEST}`
-     - `bctls-jdk15to18-{LATEST}.jar`
-     - `bcutil-jdk15to18-{LATEST}.jar`
+  본 가이드에서는 [Bouncy Castle]이라는 오픈소스 라이브러리를 이용한 예시를 설명합니다.
 
-     파일을 다운로드 받습니다.
+  1. [Bouncy Castle] 홈페이지에서 아래의 세 파일을 다운받습니다.
 
-  2. 세 jar 파일을 `${JAVA_HOME}/jre/lib/ext` directory로 복사합니다.
+     - bcprov-jdk15to18-_VERSION_.jar
+     - bctls-jdk15to18-_VERSION_.jar
+     - bcutil-jdk15to18-_VERSION_.jar
 
-  3. `${JAVA_HOME}/jre/lib/security` directory 내 `java.security` 파일을 아래와 같이 수정합니다.
+  2. 세 jar 파일을 `${JAVA_HOME}/jre/lib/ext` 디렉토리에 복사합니다.
 
-     
+  3. `${JAVA_HOME}/jre/lib/security` 디렉토리의 "java.security" 파일을 아래와 같이 수정합니다.
 
-     _추가되는 line을 제외한 나머지 기존 security provider들은 예시와 다를 수 있습니다._
-
-  4. [https://www.oracle.com/java/technologies/jce-6-download.html](https://www.oracle.com/java/technologies/jce-6-download.html)에서
-     `jce_policy-6.zip` 파일을 다운로드 받습니다.
+     
 
-  5. 압축을 푼 후
+  4. 오라클이 배포하는 "[jce_policy-6.zip]" 파일을 다운로드 받습니다.
 
-     - `US_export_policy.jar`
-     - `local_policy.jar`
+  5. 압축을 푼 후 "US_export_policy.jar", "local_policy.jar" 두 파일을 \
+     `${JAVA_HOME}/jre/lib/security` 디렉토리 내에 덮어씌웁니다.
 
-     두 파일을 `${JAVA_HOME}/jre/lib/security` directory 내에 덮어씌웁니다.
+  [Bouncy Castle]: https://www.bouncycastle.org/latest_releases.html
+  [jce_policy-6.zip]: https://www.oracle.com/java/technologies/jce-6-download.html
 

 
 ### Java 7
@@ -252,82 +277,61 @@ Cipher Suite를 지원하지 않기도 합니다.
 
 

   

-    Java 8 이상으로 버전 업그레이드
+    JDK 8u261 이상으로 버전 업그레이드
   

 
-  가장 바람직한 방법은 공식 지원기간이 이미 종료된 Java 7에서 상위 버전으로 업그레이드하는 것입니다.
-  2023년 9월에 출시된 Java 21(LTS)로 업그레이드하는 것이 가장 바람직한 방법이지만 Java 7에서 한번에 높은 버전으로 점프하는 것은 체크해야할 side effect가 매우 많습니다.
-  제일 side effect가 적으면서 합리적인 방법은 Java 8(LTS)로 업그레이드하는 것으로,
-  Java 8의 경우 default TLS 버전이 1.2이며 JDK 8u261 이상부터는 TLS 1.3 통신을 지원하기 때문에 조건에 충족합니다.
+  가장 바람직한 방법은 공식 지원이 이미 종료된 Java 7의 사용을 멈추고, Java 8 이상의 버전으로
+  업그레이드하는 것입니다. Java 8 부터 기본 TLS 버전이 1.2이고, JDK 8u261 이상부터는 TLS 1.3 통신을
+  지원하기때문에 TLS 통신을 안전하게 할 수 있습니다.
 

 
 

   

-    JDK 버전 업그레이드 및 1.2 사용 설정
+    JDK 7u321 이상으로 버전 업그레이드, 1.2 사용 설정
   

 
-  Java 7 최초 release 버전에서는 포트원에서 허용하는 Cipher suite를 지원하고 있지 않습니다.
-  해당 Cipher suite는 JDK 7u191 버전부터 지원하기 시작하였으며 JDK 7u321 버전부터 default Cipher Suite에 대한 우선순위를
-  해당 기준(FS 지원, SHA-1 미사용)에 따라 적용하므로 별도의 설정 없이 Cipher Suite 조건 충족을 만족하기 위해서는
-  JDK 버전을 7u321 이상으로 업그레이드 해야합니다.
+  JDK 7u321 버전부터 기본 Cipher Suite가 [완전 순방향 비밀성][PFS]을 지원하고 [SHA-1] 등 약한 해시를
+  사용하지 않는것으로 변경되었습니다. 따라서 JDK 7u321 이상으로 업그레이드 할 경우, 기본 TLS 버전
+  수정을 제외한 별도의 설정이 필요하지 않습니다. JDK 7u321 미만의 버전을 사용할 경우, 최소한 JDK
+  7u191 이상의 버전을 사용해야 안전하게 TLS 통신을 하기위한 Cipher Suite들을 사용할 수 있습니다.
 
-  

-
-  Cipher Suite에 대한 설정이 완료되었다면 사용 TLS 버전을 1.0에서 1.2로 설정하는 작업이
-  필요합니다. TLS 버전을 설정하는 방법은 1. System property를 설정하는 방법 2. Socket
-  client의 TLS 버전을 지정하여 설정하는 방법 2가지가 존재합니다.
+  JDK 버전업이 완료되었다면, 아래 두 방법중 하나를 골라 기본 TLS 버전을 1.0에서 1.2로 올려야 합니다.
 
   #### 1. System property
 
-  설정 `jdk.tls.client.protocols` system property를 이용해 default TLS 버전을 1.2로
-  강제하는 방법입니다. `https.protocols` system property 또한 TLS 버전 컨트롤에 이용될
-  수 있으나, 해당 property의 경우 HTTPS 통신 시 `HttpsURLConnection` class나 `URL.openstream`
-  function을 이용하는 경우에만 적용되기 때문에 `jdk.tls.client.protocols` property를
-  설정하시는 방법을 권장드립니다.
-
-  Java 애플리케이션 구동 시 아래와 같은 system property 설정을 추가합니다.
+  Java 애플리케이션 구동 시 아래와 같은 system property 설정을 추가하면, 기본 TLS 버전이 1.2로
+  변경됩니다.
 
-  ```shell
+  ```bash
   java -Djdk.tls.client.protocols="TLSv1.2" ...
   ```
 
-  주의할 점은 해당 방법은 SSL socket client에서 이용 가능한 TLS 버전을 1.2만 허용 가능하게 하는 방법으로,
-  만약 코드상으로 통신 시 TLS 버전을 1.2 이외의 버전으로 설정하고 있을 경우 에러가 발생할 수 있습니다.
+  코드에 강제로 TLS 1.2 이외의 버전을 사용하도록 하는 코드가 있을 경우, 에러가 발생할 수 있습니다.
 
   #### 2. Socket client의 TLS 버전 지정
 
-  코드상으로 socket client가 이용 가능한/통신할 TLS 버전을 직접 지정해줄 수 있습니다. 지정은 3가지 방법으로 가능합니다.
-
-  1. `SSLSocket`/`SSLEngine`/`SSLServerSocket` API를 이용
+  아래와 같이 자바 코드수준에서도 TLS socket client가 사용할 TLS 버전을 직접 지정해줄 수 있습니다.
 
   ```java
+  // SSLSocket, SSLEngine, SSLServerSocket API를 사용하는 경우
   sslSocket.setEnabledProtocols(new String[] {"TLSv1.2"});
-  ```
 
-  2. `SSLContext` 생성자를 이용
-
-  ```java
+  // SSLContext 생성자를 사용하는 경우
   SSLContext ctx = SSLContext.getInstance("TLSv1.2");
-  ```
-
-  3. `SSLParameters` API를 이용
 
-  ```java
+  // SSLParameters API를 사용하는 경우
   sslParameters.setProtocols(new String[] {"TLSv1.2"});
   ```
 

 
 

   

-    외부 라이브러리를 이용한 구현체 강제 주입
+    서드파티 라이브러리를 통한 TLS 버전 업데이트
   

 
-  Java 6 가이드에서 소개한 것과 같이 외부 라이브러리를 이용한 구현체를 강제주입하여 TLS 버전 및 Cipher Suite를 설정할 수도 있습니다.
-  방법은 Java 6 가이드의 \_3. 외부 라이브러리를 이용한 구현체 강제 주입\_과 동일합니다.
+  Java 6 가이드와 마찬가지 방법으로 서드파티 라이브러리를 통해 TLS 버전을 업데이트 할 수 있습니다.
 

 
-### Java 8
+

 
-Java 8에서는 default로 TLS 1.2 통신을 지원합니다. 만약 Java 8 버전을 쓰고 있으나 통신이 TLS 1.2 미만으로 이루어지고 있다면
-system property나 코드 레벨에서 TLS 버전을 강제하고 있는 것은 아닌지 확인이 필요하며
-만약 강제하고 있을 경우 이를 해제하여 TLS 1.2버전으로 통신 혹은 JDK 버전을 8u261 이상으로 업데이트하여 TLS 1.3을 기본적으로 사용하도록 설정이 필요합니다.
+---