레이블이 TLS인 게시물을 표시합니다. 모든 게시물 표시
레이블이 TLS인 게시물을 표시합니다. 모든 게시물 표시

2019년 2월 24일 일요일

접속 막힌 불법사이트.. SNI 필드 차단이 뭔가요?

 뉴딜코리아 홈페이지



접속 막힌 불법사이트.. SNI 필드 차단이 뭔가요?


정부가 더 강력한 불법사이트 차단 기술을 적용함에 따라 음란물, 폭력, 마약 등 불법 정보를 담은 해외 유해사이트 접근이 원천 차단됐다.

방송통신위원회는 12일 "불법음란물, 불법도박 등 불법 정보를 유통하는 해외 인터넷 사이트를 우회해서 접속하는 것을 막기위해 접속 차단 기능을 고도화했다"고 밝혔다.

11일 이후 국내 이동통신 3사를 이용 중인 사용자는 정부가 불법으로 지정한 해외 홈페이지에 접속하더라도 '연결할 수 없음'이라는 표시가 뜨게 되었다.

때문에 일각에선 표현의 자유를 위축시키고 정부가 인터넷 감청과 검열을 시도하는 것이라는 비판이 제기되고 있다.


차단에 이용된 기술은 원래 보안 취약점?

이번 접속차단에 활용된 기술은 'SNI(Server Name Indication) 필드' 차단이다.

SNI는 실제 홈페이지(IP주소)는 하나이지만 여러 주소(URL)로 접속할 수 있도록 홈페이지를 구성할 때 홈페이지 보안 인증서가 사용자에게 제대로 전달되지 않는 문제를 해결하기 위해 만든 기술이다.


현재 널리 이용되고 있는 통신 암호화 기술인 TLS 1.2(https)는 SNI 필드가 제대로 작동하도록 통신이 시작되기 전 인증 과정에서 특정 영역(도메인)을 암호화하지 않고 있다.

이렇게 인증서를 주고받기 앞서 도메인 정보가 암호화되지 않는 것은 TLS 1.2의 대표적인 보안 결함으로 꼽히고 있다.

이러한 문제를 해결하기 위해 지난해 8월 애플(사파리), 모질라재단(파이어폭스), 구글(크롬), 클라우드플레어 등 인터넷 관련 업체들이 모여 신규 암호통신 표준인 TLS 1.3을 제안한 상태다.

즉, 정부는 TLS 1.2의 보안 취약점을 활용해 불법 홈페이지 차단을 시행한 셈이다.


정부가 불법 홈페이지를 차단하기 위해 가장 먼저 이용한 방법은 단순 URL 주소 차단이다.

 하지만 통신 정보가 암호화되는 https를 활용하면 쉽게 무력화되는 단점이 있었다.

이를 해결하기 위해 DNS(Domain Name System, 숫자로 된 IP 주소를 영어나 한국어로된 일반 주소로 바꿔주는 기술)를 활용한 차단법을 선보였다.

하지만 이 역시 앱이나 프로그램 등으로 손쉽게 우회할 수 있었다.

완벽한 불법 홈페이지 차단법을 찾다가 결국 통신 감청으로 이해될 수도 있는 SNI 필드 차단이란 극단적인 선택까지 한 것으로 풀이된다.


이제 막 시작된 TLS 1.3... 완벽한 통신 보안은 언제 가능할까

정부의 이번 SNI 필드 차단은 TLS 1.3이 적용된 웹 브라우저와 서버에는 적용되지 않는다.

인증서를 주고받기 앞서 도메인 정보까지 모두 암호화하기 때문이다.

하지만 TLS 1.3은 이제 막 발걸음을 뗀 기술이다.

웹 브라우저에는 하나둘씩 관련 기술이 적용되고 있지만, 호스팅 서비스를 제공하는 업체들은 아직 TLS 1.3에 맞게 서버 업그레이드를 실시하지 않았다.

최신 버전 크롬, 파이어폭스, 사파리 등에선 TLS 1.3를 이용할 수 있으나, TLS 1.3이 적용된 서버 업체는 미국의 클라우드플레어가 유일하다.

TLS 1.2는 2008년에 개발된 기술임에도 본격적으로 웹 환경에 적용되기까지 5년이 넘는 시간이 걸렸다.

TLS 1.3 역시 업체들의 이해관계 때문에 모든 웹 브라우저와 서버(웹 사이트)에 적용되려면 다소 시간이 걸릴 전망이다.

한 업계 관계자는 "TLS 1.3이 활성화되려면 결국 호스팅 업체들의 기술 업그레이드가 필요하다"며, "미국의 호스팅, 클라우드 업체를 중심으로 TLS 1.3을 지원하려는 움직임이 활발해지고 있다"고 밝혔다.


TLS 1.3 활성화 방법

크롬: URL 창에 'chrome : // flags' 입력 후 TLS 1.3을 검색해서 활성화

파이어폭스: URL 창에 'about : config' 입력 후 'security.tls.version.max'를 검색해서 기본값을 3에서 4로 변경

두 웹 브라우저 모두 기본적으로 TLS 1.3이 꺼져있다.

TLS 1.2와 완벽환 호환을 보장할 수 없기 때문이다.

따라서 TLS 1.3가 적용된 홈페이지를 접속하고 난 후 다시 설정을 원래대로 돌려주는 편이 좋다.

글 / IT동아 강일용


컨설팅 : ISMS, ISO27001  GDPR,PCI-DSS 
취약점 진단 및 모의 침투
개인정보 비식별화 솔루션
보안솔루션 공급
070-7867-3721, ismsbok@gmail.com
 

2018년 11월 11일 일요일

주요 웹 브라우저 2020년 TLS1.0 및 TLS1.1 통신 지원 중지


주요 웹 브라우저 2020년 TLS1.0 및 TLS1.1 통신 지원 중지
(BROWSER VENDORS UNITE TO END SUPPORT FOR 20-YEAR-OLD TLS 1.0)

Chrome, Firefox, Edge, Safari, Explorer를 포함한 주요 웹 브라우저가 2020년에 TLS 1.0 및 TLS 1.1 통신에 대한 지원을 중지한다고 발표



■ TLS의 초기버전인 TLS1.0, TLS1.1은 POODLE 및 BEAST와 같은 다양한 공격에 취약

▷ SSL Protocol을 기반으로 개발된 TLS는 클라이언트-서버 간 안전하고 암호화된 통신 채널을 설정하는데 사용되고 있음

▷ POODLE(Padding Oracle On Downgraded Legacy Encryption) 취약점 : 구식 암호화 기법을 악용할 수 있게 하는 프로토콜 다운그레이드 취약점

▷ BEAST(Browser Exploit Against SSL/TLS) 취약점 : 앤드 유저 브라우저에서 HTTPS의 쿠키들을 해독하고 효과적인 타킷의 세션을 하이제킹할 수 있는 취약점

▷ TLS는 현재 1.0, 1.1, 1.2, 1.3(최신)으로 총4개의 버전 존재



TLS1.2 이상으로 업그레이드하고 브라우저 옵션에서 TLS1.0, TLS1.1 사용옵션 해제 권장

▷ PCI Data Security Standard(PCI DSS)*, Gitlab 등 업체들이 올해 안에 하위 버전 지원 중단

  * 신용카드 회원의 카드정보 및 거래정보를 안전하기 관리하기 위해 신용카드 결제전 과정에 결쳐 준수하여야 하는 신용업계 보안표준

▷ Google, Microsoft, Apple, Mozilla 등 4대 주요 회사는 2020년 상반기에 TLS1.0 및 TLS1.1 지원을 완전히 삭제 예정


▷ MS는 이미 많은 웹사이트가 새로운 버전의 프로토콜로 이동하였으며, 현재 사이트의 94%가 TLS1.2를 지원하고 있음


[참고]


컨설팅 : ISMS, ISO27001  GDPR,PCI-DSS 
취약점 진단 및 모의 침투
보안솔루션 공급
070-7867-3721, ismsbok@gmail.com


2018년 10월 16일 화요일

Office 365에서 TLS 1.2의 사용을위한 준비 (필수)

 뉴딜코리아 홈페이지 

Office 365에서 TLS 1.2의 사용을위한 준비







■ 2018 년 10 월 31, 현재 Microsoft Office 365에서 TLS (Transport Layer Security) 버전 1.0 및 1.1에 대한 지원을 곧 중단 할 계획

- 프로토콜 다운 그레이드 공격 및 기타 TLS 취약점이 발생할 수 있으므로 Office 365에서 TLS 1.0 및 1.1 사용에 대한 지원을 중단 할 예정

- Applies to:   Office 365 Business, SharePoint Server 2010, SharePoint Server 2013, SharePoint Server 2016,

- 참고 :
  . https://support.microsoft.com/ko-kr/help/4057306/preparing-for-tls-1-2-in-office-365
  . https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365


☞ 첨부파일 : TLS 1.0 문제 해결


컨설팅 : ISMS, ISO27001  GDPR,PCI-DSS 

취약점 진단 및 모의 침투
보안솔루션 공급
070-7867-3721, ismsbok@gmail.com


2018년 8월 11일 토요일

TDES 암호알고리즘의 사용제한 권고(NIST)

 뉴딜코리아 홈페이지 

NIST, TDES 암호알고리즘의 사용제한 권고 .. (금융보안원)

○ 최근 NIST에서는 구조적 취약성을 이유로 특정 암호알고리즘의 용도에 따른 사용제한을 권고함


1. NIST 소개

○ NIST(미국 국립표준기술연구소): 미국 상무부 산하 기관으로서 컴퓨터 보안, 정보기술 분야와 관련된 미국 내의 표준 지정 및 가이드라인, 권장사항, 기술 사양 등의 간행물을 배포

○ NIST 문서: 암호를 포함한 정보기술 등 관련 분야에서 국제적인 로드맵을 주도하는 역할을 하고 있음


※ 우리나라 고시, 가이드라인, 안내서에 명시된 ‘안전한 암호 알고리즘’은 국내·외 전문기관 (KISA, NIST, ECRYPT, CRYPTREC 등)이 권고하는 암호알고리즘을 뜻함

◦ 2018년 7월에 개정된 NIST표준문서(SP800-131A1))의 주요 개정 사항은 TDES 암호알고리즘*의 사용중지 계획이며,  (SP800-131A: 안전한 암호알고리즘의 종류와 사용 권고 기간을 제시하고 있기 때으며, 국내·외에서 알고리즘의 보안성을 확인 할 때 주로 참고)

* NIST에서는 TDEA(Triple Data Encryption Algorithm)로 표기하며, 국내에서는 TDES(Triple Data Encryption Standard) 또는 3DES로 표기함)

- 동 표준은 2030년까지로 안전성을 허용했던 TDES의 사용을 점진적으로 중지하도록 권고하고 있음


2. TDES의 보안 취약점

(가) TDES의 소개

○ (특징) TDES는 DES*를 세 번 연이어 연산**하는 암호알고리즘으로 1998년 배포(ANSI X9.52 문서)되었고, DES와 동일한 블록크기(64bit)를 가지는 블록암호임

 * DES는 64bit의 평문을 56bit의 키로 암호화 하는 구조적 특징을 가짐
 ** TDES연산: DESkey1암호화 – DESkey2복호화 – DESkey3암호화 연산을 수행

<참고 : 블록암호의 보안성>
 블록암호: 기밀성 있는 정보를 정해진 블록 단위로 암호화하는 대칭키 암호 시스템 
블록암호의 보안성: 비밀키 길이가 k비트일 때 2(K)개의 비밀키 후보중에서 암호화에 사용된 키를 찾는 것에 의존

- 컴퓨팅 파워가 증가하면서 DES의 보안강도가 약해졌으나, 다른 암호알고리즘이 제시되기 전까지 TDES를 임시로 사용

※ 2000년 10월 이후, 128bit 이상의 블록크기를 갖는 블록암호알고리즘(AES, ARIA, SEED 등)이 등장


○ (종류) 세 번의 DES 연산에서 서로 다른 세 개의 암호키를 사용하는 ‘3키 TDES’와 암호키 준비(키 스케줄링) 시간을 줄이기 위해 두 개의 암호키만 사용하는 ‘2키 TDES’가 있음

- 2키 TDES는 2015년 이후로 암호화 용도로 사용 중지

- 3키 TDES는 2030년까지 사용 가능한 것으로 권고해왔음





○ (사용처) Windows XP 등 이전 운영체제 및 이전 프로토콜 (SSL, 초기 TLS 등)에서 전송 및 저장 중 계정 데이터를 보호하기 위한 방법으로 결제환경에서 자주 사용되었으며,

- 현재는 이전 운영체제와 이전 프로토콜과 호환을 위해 일부 제품에서 선택사항으로 TDES암호알고리즘을 탑재하고 있음


(나) TDES의 보안 취약점

○ TDES는 DES의 암호연산 구조상 특징으로 인해 특정 환경에서 비밀키와 상관없이 평문을 알아낼 수 있는 공격에 취약

- TDES는 현재 국내·외에서 권고하는 다른 블록암호*에 비해 작은 블록크기(64bit)를 가짐
  * AES, ARIA, SEED 등의 128bit이상 블록크기를 갖는 암호알고리즘

- 특정 운영모드에서 서로 다른 입력 값임에도 암호화된 결과 값이 동일한 ‘충돌’ 이 일어날 확률이 큼(일반적으로는 해시값 충돌처럼 입력값 대비 출력값의 경우의 수가 더 적을 때 일어나는 현상을 말하며, TDES와 같은 대칭암호에서는 동일한 암호키와 동일 암호알고리즘에서 서로 다른 입력값에 의한 암호 출력값이 동일한 경우, 충돌이라고 함)

<참고 : 운영모드의 보안성>
운영모드: 블록암호 사용 시 암호화하려는 정보가 블록 길이보다긴 경우, 블록암호를 처리하는 형태
운영모드의 보안성: 사용된 블록암호의 블록 크기에 영향을 받음

- 충돌이 일어날 경우, 충돌된 암호 출력값에서 암호키 없이 입력값을 추측할 수 있음 (CVE-2016-2183, Sweet32 취약점은 TLS 64bit 생일공격으로서 블록암호 SSL/TLS 중 특정 설정에서 충돌을 일으켜서 암호화 데이터 중 평문을 추측해 내는 취약점)

○ 특히, 다음의 환경에서 TDES가 활용 될 때 보안성에 큰영향을 줌

   ①동일한 비밀키가 중복되어 사용되는 환경,

   ②일부 평문을 공격자가 알고 있는 환경

- TDES가 TLS, IPSec, SSH와 같은 프로토콜에서 사용되는 경우, 프로토콜 보안성에 영향을 미침



☞ 추가 상세 내용은 첨부파일을 참고 하세요 .(click)


컨설팅 : ISMS, ISO27001, GDPR, PCIDSS 
취약점 진단 및 모의 침투
보안솔루션 공급
070-7867-3721, ismsbok@gmail.com

2017년 12월 18일 월요일

OpenSSL 신규 취약점 보안 업데이트 권고 (2017-12-07)

 뉴딜코리아 홈페이지 




OpenSSL 신규 취약점 보안 업데이트 권고 (2017-12-07)


□ 개요
 o OpenSSL에서 서비스 거부 공격이 가능한 취약점을 해결한 보안 업데이트 발표

"error state" 상태에서 SSL_read() 혹은 SSL_write() 함수를 호출할 때, "error state"메커니즘의 버그 때문에 원래의 의도대로 동작하지 않게 됩니다.

이 때문에 원래 데이터가 OpenSSL을 통해 데이터가 암/복호화 되어야 하는데, 더 이상 SSL/TLS 레이어에서 암/복호화 처리가 불가하게 됩니다.

심각도 : 낮음 (Severity: Low)

□ 설명
 o OpenSSL 1.0.2 (버전 1.0.2b에서 시작)에 메커니즘 "error state" 버그 발생

핸드 셰이크가 진행되는 과정에서 SSL_read() 및 SSL_write() 함수 호출 시 오류가 발생할 경우, 데이터가 암호화 되지 않고 전달되어 정보노출이 발생하는 취약점(CVE-2017-3737)

이는 SSL_read () 또는 SSL_write ()가 직접 호출되면 버그로 인해 명시 적 핸드 셰이크 함수 (SSL_do_handshake (), SSL_accept () 및 SSL_connect ())로 설계된 것처럼 작동하지만 버그로 인해 올바르게 작동하지 않습니다.

이 시나리오에서 핸드 셰이크에 실패하면 초기 함수 호출에서 치명적인 오류가 반환됩니다.
SSL_read () / SSL_write ()가 동일한 SSL 객체에 대한 응용 프로그램에 의해 연속적으로 호출되면 성공하고 데이터는 SSL/TLS 레코드 계층에서 직접 암/복호화 되지 않고 전달됩니다.


OpenSSL 버전 1.0.2b-1.0.2m이 영향을받습니다.

OpenSSL 1.0.2n에서 수정되었습니다.

OpenSSL 1.0.2을 사용하는 사용자들은 OpenSSL 1.0.2n버전으로 업데이트

OpenSSL 1.1.0은 영향을받지 않습니다.
※ OpenSSL v1.1.0은 영향 받지 않으며, v1.0.1은 지원종료 됨



[참고 자료]

OpenSSL Security Advisory [07 Dec 2017]
========================================

Read/write after SSL object in error state (CVE-2017-3737)
==========================================================

Severity: Moderate

OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism.
The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake.
This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly.
In that scenario, if the handshake fails then a fatal error will be returned in the initial function call.
If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer.

In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error.

This issue does not affect OpenSSL 1.1.0.

OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 10th November 2017 by David Benjamin (Google).
The fix was proposed by David Benjamin and implemented by Matt Caswell of the OpenSSL development team.

rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738)
=========================================================

Severity: Low

There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli.
No EC algorithms are affected.
Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely.
Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline.
The amount of resources required for such an attack would be significant.
However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701.

This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation).
Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193.

Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available.
The fix is also available in commit e502cc86d in the OpenSSL git repository.

OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin (Google).
The issue was originally found via the OSS-Fuzz project.
The fix was developed by Andy Polyakov of the OpenSSL development team.

Note
====
Support for version 1.0.1 ended on 31st December 2016.
Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015.
Those versions are no longer receiving security updates.

References
==========
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20171207.txt
Note: the online version of the advisory may be updated with additional details over time.
For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html



취약점 분석 & 모의 침투
컨설팅사업부 (070-7867-3721, ismsbok@gmail.com)




2016년 5월 27일 금요일

Gmail SMTP에 대해서 SSLv3/RC4 지원 중단

카페 > 뉴딜코리아 홈페이지 | 뉴딜코리아
http://cafe.naver.com/rapid7/2463


 Gmail SMTP에 대해서 SSLv3/RC4 지원 중단



2016년 6월 6일
Disabling support for SSLv3 and RC4 for Gmail SMTP in 30 days

Last September, we announced plans to no longer support two very old security systems called SSLv3 and RC4. As mentioned in Adam Langley’s announcement, these systems are no longer secure and pose a risk to those still using them:

SSLv3 has been obsolete for over 16 years and is so full of known problems that the Internet Engineering Task Force (IETF) has decided that it must no longer be used.

RC4 is a 28-year-old cipher that has done remarkably well, but is now the subject of multiple attacks at security conferences. The IETF has decided that RC4 also warrants a statement that it too must no longer be used.

Because of these issues, after June 16, 2016, we will disable both SSLv3 and RC4 support at Google’s SMTP servers and on Gmail’s web servers.


▶ If you are still using SSLv3 or RC4: 


. 사용중인 SSLv3 및 RC4를 중지 하고 최신 TLS 구성으로 업데이트
 
  Most organizations on Google Apps have already stopped using SSLv3 and RC4; however, if you are still on these older systems, we recommend reviewing the suggested actions in the Security Blog announcement and updating to modern TLS configurations.

  Some common systems that may still be using SSLv3: inbound/outbound gateways, third-party emailers, and systems using SMTP relay.

 

이후는 SSLv3 and RC4 이용한 Google’s SMTP servers 접속이 제한됩니다
  
 After this change, servers sending messages via SSLv3 and RC4 will no longer be able to exchange mail with Google’s SMTP servers, and some users using older and insecure mail clients won't be able to send mail.

More InformationDisabling SSLv3 and RC4