|
$ cd /etc/apt
$ sudo vi apt.conf
if apt.conf file not exist. create new file.
add below lines from vi editor then save.
Acquire::http::proxy "http://ipaddress:port/";
$ sudo apt-get update
$ sudo apt-get upgrade
| ubuntu - flash plugin install (0) | 2014.12.04 |
|---|---|
| ubuntu fire fox - Connection Untrusted (0) | 2014.12.04 |
| untu 12.04에서 apache2 + tomcat7 mod_jk 연동처리 (0) | 2013.10.25 |
| git 사용법 (0) | 2013.07.29 |
| ubuntu 12.04 함글 (0) | 2013.04.08 |
서비스 삭제
Method 3 - manually delete registry entries (Note that this backfires in Windows 7/8)
Windows services are registered under the following registry key.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicessc stop <service-name>
sc delete <service-name>
------------
파일 소유권 변환
takeown /F <file-name>
폴더 소유권 통째로 변환
takeown /F <folder-name> /r /d y
------------------
권한 변경
You should use icacls instead. This is how you grant John full control over D:\test folder and all its subfolders:
C:\>icacls "D:\test" /grant John:(OI)(CI)F /T
According do MS documentation:
F = Full ControlCI = Container Inherit - This flag indicates that subordinate containers will inherit this ACE.OI = Object Inherit - This flag indicates that subordinate files will inherit the ACE./T = Apply recursively to existing files and sub-folders. (OI and CI only apply to new files and sub-folders). Credit: comment by @AlexSpence.For complete documentation, you may run "icacls" with no arguments or see the Microsoft documentation here and here
|
You can also use ICACLS. To grant the Users group Full Control to a folder: To grant Modify permission to IIS users for If you do ICACLS /? you will be able to see all available options. |
CACLS files /e /p {USERNAME}:{PERMISSION}
Where,
/p : Set new permission
/e : Edit permission and kept old permission as it is i.e. edit ACL instead of replacing it.
{USERNAME} : Name of user
{PERMISSION} : Permission can be:
R - Read
W - Write
C - Change (write)
F - Full control
For example grant Rocky Full (F) control with following command (type at Windows command prompt):
C:> CACLS files /e /p rocky:f
Read complete help by typing following command:
C:> cacls /?
I try the below way and it work for me:
1. open cmd.exe
2. takeown /R /F *.*
3. icacls * /T /grant [username]:(D)
4. del *.* /S /Q
So that the files can become my own access and it assign to "Delete" and then I can delete the files and folders.
---------------------------------------
| windows 10 시작프로그램 (0) | 2018.10.24 |
|---|---|
| ffmpeg 사용해서 mp4, aac 등 합치기 (0) | 2018.06.07 |
| SSLv3, TLSv1 (0) | 2017.09.25 |
| windows 10 에서 wmencoder64 설치 (0) | 2017.01.01 |
| windows 10 최적화 (0) | 2016.12.19 |
안녕하세요.
2014년 접어들면서,
아니 그 이전부터 그랬었겠지만 이제 SSL은 쓰지 않는것을 권고하고 있습니다.
아래와 같이 보안 취약점이 발견된 건데요.
| SSL 3.0 웹 암호화 기술에서 보안 취약점이 발견됐다. 데이터 보안을 위해 전송 데이터를 암호화하는 이 기술이 오히려 암호화가 풀려 해커에게 노출되는 취약점이다. 하트블리드나 배쉬버그 등과 비교해서는 위험한 수준이 아니지만, 주의가 필요하다. 15일 주요 외신들에 따르면, 구글 소속 연구원들이 SSL3.0 웹 암호화 기술의 보안 취약점을 찾아 공개했다. 푸들(Poodle, Padding Oracle On Downloaded Legacy Encryption)이라고 명명된 이 취약점은 다운그래이드 댄스(Downgrade Dance)공격을 통해 SSL 3.0을 사용하도록 강제하고 중간 공격자가 보호된 HTTP 쿠키의 암호를 풀 수 있도록 하는 방식이다. 즉, 서버와 클라이언트간에 오가는 데이터가 암호화되야 정상적이지만, 데이터 전송 중간에서 암호화가 풀려 공격자에게 내용이 노출될 수 있는 버그다. 구글 연구자들은 SSL3.0 취약점 사고를 막기 위해선 SSL3.0 기술을 서버나 브라우저에서 비활성화하는 한편, 보다 강력한 암호화 방식인 TLS을 사용하도록 권고했다. |
이에 관하여, TLSv1 웹 암호화 방식을 사용하게 되었습니다.
그럼 SSLv3 와 TLSv1 이 뭔가를 살펴보도록 하겠습니다.
| 참고, SSLv2 vs SSLv3/TLS 1. SSLv2는 MD5 해쉬를 사용해서 MAC 생성 2. SSLv2는 핸드쉐이크 중 보호를 받지 못함. Man-in-the-middle attack 취약 3. SSLv2는 truncation attack에 취약(공격자가 TCP-FIN를 보내서, 연결을 종료시킴), SSLv3는 명시적인 종료 신호를 보냄. 참고. WTLS vs TLS 1. WTLS는 Elliptic curve cryptography(ECC)를 기본으로 사용 2. WTLS는 UDP를 사용 3. WTLS는 무선 환경을 고려하여 작은 크기의 인증서 사용 |
| 암호화 프로토콜은 보안 연결을 제공하여 두 당사자가 사생활 보호와 데이터 무결성을 가지고 서로 통신할 수 있도록 해줍니다. TLS(Transport Layer Security) 프로토콜은 SSL(Secure Socket Layer) 프로토콜에서 발전한 것입니다. WebSphere® MQ는 SSL과 TLS를 모두 지원합니다. 두 프로토콜의 주요 목표는 기밀성(때로는 사생활 보호라고도 함), 데이터 무결성, ID 및 디지털 인증서를 사용한 인증을 제공하는 것입니다. 두 프로토콜이 유사하긴 하지만 SSL 3.0과 TLS의 다양한 버전이 상호 운용되지 않는다는 점은 상당한 차이점입니다. |
| * SSL 및 TLS가 ID, 인증, 기밀성 및 무결성을 제공하는 방법 - Server 인증에는 Client가 비밀 키를 처리하는데 사용되는 데이터를 암호화하기 위해 서버의 공개키를 사용 - Server 가 정확한 개인키로 데이터 비밀번호를 해독하는 경우에만 비밀키를 생성 - Client 인증에는 Server가 데이터 교환의 5단계 동안에 Client가 송신하는 데이터의 비밀번호를 해독하기 위해 클라이언트 인증서에 있는 공개키를 사용 - 비밀 키로 암호화된 자료 해독 * 인증 단계 중 어느 것이든지 실패하면, 데이터 교환이 실패하고 세션이 종료됩니다. - SSL , TLS 데이터 교환 중의 디지털 인증서 교환은 인증 프로세스 부분 - 인증서가 위장에 대해보호를 제공하는 방법에 대한 자세한 정보는 아래 참고하시기 바랍니다. (CA x = SSL,TLS Client에 인증서 발행) (CA y = SSL,TLS 서버에게 인증서 발행) * Server 인증 필요한 것 - CA y 가 Server에게 발행한 개인 인증서 - 서버의 개인키 * Client 인증 필요한 것 - CA y 의 CA 인증서 * 인증서 확인 - 디지털 서명을 점검합니다 - 중간 CA 인증서를 가지고 있어야 하는지 확인하기 위해 인증서 체인을 점검합니다 (인증서 체인이 작동하는 방법)
- 만기 및 활성화 날짜와 검증 기간을 점검합니다. - 인증서의 폐기 상태를 점검합니다* 비밀키 - SSL 또는 TLS 데이터 교환 중에 SSL 또는 TLS 클라이언트와 서버 간의 데이터를 암호화하기 위해 비밀 키가 생성됩니다. 비밀 키는 일반 텍스트를 읽을 수 없는 암호문으로 변환하고 암호문을 일반 텍스트로 변환할 수 있도록 데이터에 적용되는 수학 공식에서 사용됩니다. - 비밀 키는 데이터 교환의 일부분으로 송신되는 임의 텍스트에서 생성되며 일반 텍스트를 암호문으로 암호화하는 데 사용됩니다. 또한 비밀 키는 메시지의 대체 여부를 판별하는 데 사용되는 MAC(Message Authentication Code) 알고리즘에 사용됩니다. * 기밀성을 제공하는 방법 - SSL,TLS는 메시지 비공개를 보장하기 위해 대칭과 비대칭 암호화의 결합을 사용합니다. - SSL,TLS 데이터 교환 중에 SSL,TLS 클라이언트와 서버는 하나의 세션에만 사용될 암호화 알고리즘과 공유 비밀 키에 동의합니다. - SSL,TLS 클라이언트와 서버 사이에 전송되는 모든 메시지는 해당 알고리즘과 키를 사용하여 암호화됩니다. - 누군가가 메시지를 가로채더라도 반드시 개인용으로 남아있게 됩니다. - SSL은 광범위한 암호화 알고리즘을 지원합니다. - SSL 및 TLS가 공유 비밀 키를 전송할 때는 비대칭 암호화를 사용하기 때문에, 키 분배 문제점이 없습니다. * 무결성을 제공하는 방법 - SSL,TLS는 메시지 축약을 계산하여 데이터 무결성을 제공합니다. - SSL,TLS를 사용하는 경우, 채널 정의 내의 CipherSpec이 CipherSpec 지정의 테이블에서 설명한 대로 해시 알고리즘을 사용하는 한 데이터 무결성이 보장됩니다. |
------------------------------------
https://eastdg.wordpress.com/2014/04/09/ssltls-%EA%B8%B0%EB%B3%B8/
Leave a comment
글을 쓴지 거의 1년이나 지나버렸다. 평소 생활이 바쁜 것도 있지만, 게으른 것도 있으리라. 내 생각이 담긴 글은 아니고.. 보안에 관심은 있는데 관련 업종이 아니니 자주 접하질 못하고, 또 자꾸 잊어먹기도 하여 틈틈이 개념들을 정리해 놓곤 하는데, 그 중 하나인 SSL/TLS과 관련된 글이다. Stackexchange에서 “How does SSL work?” 질의에 대한 답변(특히 Thomas Pornin의 답변)을 보고 정리한 것이다. 오역도 있고 그럴테지만 기본 적인 개념을 쌓는데는 충분하다고 생각되고, 글도 올린지 너무 오래되어 이 글을 올려본다. 그리고 최근(14년 4월 7일) OpenSSL 1.0.1 버전 부터 1.0.1f 버전에 매우 심각한 버그가 있음이 발견되었다. 해당 버전의 OpenSSL을 사용하고 있으면 heartbeat를 이용하여 메모리에 상주하고 있는, 비밀키를 포함한 모든 정보를 가져갈 수 있다. 자세한 내용은 Heartbleed Bug를 참고하고, 현재 사용하고 있다면 빨리 패치해야 한다.
최초의 SSL은 Netscape사에서 개발되었다. SSL의 목적은 안전하지 않은 전문들을 암호화 하여 안전하게 전달하기 위해서이다. SSL 버전 1은 실제로 발표되진 않았었고, SSL 버전 2가 이후 공개적으로 발표가 되었는데 많은 보안 취약점이 있었다. 그래서 그것을 보안한 것이 SSL 버전 3이며 공식적으로 표준화 한 이름이 TLS 이다. 이를 같이 묶어서 SSL/TLS 라고 부른다. 좀 더 자세히 말해 보자면 아래와 같이 버전이 대입된다.
TLS는 현재 TLS 1.0, TLS 1.1 그리고 TLS 1.2 버전으로 나뉘어져 있으며, 보안상 TLS 1.2가 가장 강력하다. 하지만 아직까지도(2013년) TLS 1.2를 지원하지 않는 브라우저나 애플리케이션이 존재하기 때문에 TLS 1.2만 쓰지는 않고 TLS 1.1 등을 같이 지원하면서 사용한다. SSL/TLS의 가장 큰 목적은 상호간에 데이터를 매우 안전하게 전달하는 것에 있다. TCP는 패킷 이라는 단위를 통하여 데이터를 전송한다. 이 패킷은 악의적인 공격자에 의하여 쉽게 탈취가 가능하며, 공격자는 탈취한 패킷을 임의의 데이터로 조작하여 재 전송을 할 수 있다. 전송해야 할 데이터가 모두 노출이 되어 있기 때문에 가능한 일이다. 이를 방지하도록 도움을 주는 것이 SSL/TLS 이다. SSL/TLS는 TCP/IP 위에서 동작한다. 그렇기 때문에 몇몇 사람들에 의하여 네트워크의 OSI 레이어 중 TCP/IP 레이어 인지, Application 레이어인지 갑론을박이 벌어지기도 한다. 이 2개의 레이어에 속하도록 하는 것이 아니라 이 2개의 레이어 사이에 있다고 보는게 더 적당한 것 같다. 아무튼 이 SSL/TLS는 TCP/IP 위에서 동작하기 때문에 SSL/TLS의 목적인 보안성과 함께 TCP/IP의 안정성까지 가지고 있다.
SSL/TLS의 가장 하위 단은 record protocol이다. TCP가 데이터를 패킷으로 나뉘어 사용하듯이 SSL/TLS은 데이터를 record(이하 레코드) 단위로 나뉘어 사용한다. 레코드는 아래와 같은 형태로 되어 있다.
HH V1V2 L1L2 data
각 필드들은 아래와 같다.
이 이후에는 대칭키 암호로 암호화 된 데이터와 무결성 검사용 데이터들이 최대 18KB가 온다. 복호화 할 때 쓰이는 키와 사용되는 암호화 알고리즘, 그리고 무결성 체크 알고리즘은 이미 상호간에 기 교환된 알고리즘들로 체크하게 된다. 만약 압축 기법을 서로 사용하기로 했다면 상호간에 사용하기로 한 압축 기법으로 해제도 수행한다. 대략적인 과정은 아래와 같다.
HMAC은 MD5, SHA-1 이나 SHA-256 등을 이용하여 구성하고, 암호화는 block cipher인 경우 CBC 모드를, stream cipher인 경우에는 RC4를 사용한다. HMAC는 전송될 데이터와 연결 순서와의 조합에서 생성하기 때문에 공격자는 레코드를 바꿔치지 못하게 된다.
Handshake는 레코드 단위에서 동작되는 행동이며, SSL/TLS의 레코드에 적용할 알고리즘과 키를 교환하는 것에 목적이 있다. 이 handshake를 마치고 나면 오직 둘만이 소통할 수 있는 세션(session)이라는 통로가 생성된다. Handshake는 메시지들로 구성되어 있는데, 각각의 메시지들은 4개의 바이트 헤더를 가지고 있으며 메시지는 레코드 형태로 전송이 된다. 레코드 형식으로 전송되므로 레코드에서 사용하는 헤더도 역시 포함되어 전송이 된다. 헤더의 첫 번째 바이트는 메시지의 타입을 나타내며 3 바이트는 메시지의 길이를 나타낸다. (빅 엔디언 방식으로 표시된다.) 메시지들은 레코드 형식으로 다시 보내지므로 여기서 레코드에서 사용하는 타입은 22를 사용한다. SSL/TLS 를 시작하기 위한 최초의 교신은 암호화와 MAC 없이 시작한다. 최초의 메시지는 ClientHello 라고 불리우며 클라이언트(Client)가 SSL 통신을 시작하기 원한다는 것을 뜻한다. ClientHello가 포함하고 있는 내용은 아래와 같다.
Cipher suite는 16 비트로 사용할 암호화 기법을 정의한다. 예로 TLS_RSA_WITH_AES_128_CBC_SHA는 0x002F로 표현되며 나타내는 바는 HMAC/SHA-1과 128 비트 키로 AES 암호화를 사용하며, 키 교환은 RSA로 수행하겠다는 뜻이다. ClientHello의 응답으로 서버는 ServerHello를 보낸다. ServerHello는 다음과 같은 내용을 포함하고 있다.
전체적인 Handshake는 아래와 같은 형식으로 진행 된다.
Client Server
ClientHello -->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -->
[ChangeCipherSpec]
<-- Finished
Application Data <-> Application Data
ClientHello와 ServerHello를 마치면 사용하는 cipher suite와 다른 인자 값들에 따라 몇몇의 메시지들을 서버는 추가로 보내게 된다.
위와 같은 메시지를 서버에게 받으면 클라이언트는 아래와 같이 응답을 해줘야 한다.
ChangeCipherSpec은 handshake 메시지가 아니다. 레코드 타입(타입 20번) 중 하나로서 발송되며 cipher suite를 서버와 다시 협의하게 된다. Finished 메시지는 이전의 서버와 클라이언트간 모든 handshake 메시지들을 가지고 암호학적인 체크섬을 계산한 것이다. 서버는 이 값을 받으면 재 계산을 통하여 자신이 계속 똑같은 클라이언트와 교신을 했는지 검증하게 된다. 클라이언트가 ChangeCipherSepc을 요청하였다면 서버는 그에 대한 응답을 해주고, Finished 응답을 해준다. 이것으로 상호간 SSL/TLS을 이용하여 교환하고자 하는 데이터를 전송하게 된다. Session ID를 기억하고 있다면 위와 같은 Full Handshake를 이용하지 않아도 된다. Abbreviated Handshake를 이용하면 되는데 아래와 같이 절차가 매우 간단하다.
Client Server
ClientHello -->
ServerHello
[ChangeCipherSpec]
<-- Finished
[ChangeCipherSpec]
Finished -->
Application Data <-> Application Data
Abbreviated Handshake는 latency를 줄이기 위해 자주 사용된다. 일반적인 웹 브라우저는 SSL 연결을 Full Handshake를 통하여 열고 나머지는 모두 Abbreviated Handshake를 통하여 교신을 한다. 그리고 일반적인 웹 서버들은 약 15초간 아무일을 하지 않으면 연결을 끊지만 session ID를 기억하고 있기 때문에 언제든지 Abbreviated Handshake를 통하여 SSL 연결을 다시 열 수 있다.
SSL/TLS이 사용할 수 있는 몇몇 키 알고리즘들이 있는데, 대부분의 키 알고리즘들은 서버의 공개키를 이용하여 동작한다. 다음은 많이 쓰이는 키 알고리즘 들이다.
다음은 보안상이나 기타 다른 이유로 잘 쓰이지 않는 키 알고리즘들이다.
현 시점에서는 elliptic curves를 이용한 DH* 알고리즘을 지원하는 클라이언트가 그리 많지 않다. 그리고 대부분의 클라이언트가 RSA 또는 DHE_RSA를 지원하기 때문에 이 2개를 먼저 고려하게 될 것이다. 이 2개중 어느것이 더 괜찮냐고 물어본다면 DHE_RSA가 더 괜찮다. 이유인즉 RSA경우 만약에 공격자가 서버의 비밀키를 획득하게 된다면 이전의 모든 SSL/TLS 전문들을 다시 복호화 할 수 있기 때문이다. DHE_RSA인 경우에는 별도로 교환된 키로 암복호화 하기 때문에 이전의 SSL/TLS 전문들을 다시 복호화 하기는 힘들다.
디지털 인증서는 비 대칭키이므로 해당 키를 어떻게 분배할 것인가에 대하여 꽤 깊은 고민을 해봐야 한다. 이유인즉, 클라이언트는 서버의 공개키를 사용하여 비밀 통신을 하고 싶지만 공격자는 중간에 자신의 공개키를 서버의 공개키라고 속이고 비밀 통신을 유도할 수 있기 때문이다. 이를 방지하기 위해 표준 인증서인 X.509를 사용한다. X.509는 공인 인증기관(Certification Authority 또는 CA)에서 서명한 인증서로서 클라이언트가 서버의 인증서가 진짜임을 CA가 서명한 것으로 판단할 수 있게 도와준다. CA 서명 기법은 다른 CA들이 추가로 서명을 해줄 수 있는데, 이렇게 함으로써 인증서의 보안성을 높이기도 한다. 이러한 인증서들은 chain of certificates라고도 하는데, 맨 처음은 root CA의 인증서부터 시작해서 중간마다 intermediate CA들 인증서, 그리고 맨 마지막에는 서버의 인증서로 끝난다. 그리고 각각의 인증서들은 이전 인증서로 서명된 값들을 포함하고 있다. 즉, 아래와 같이 클라이언트는 서버 인증서를 검증할 수 있다고 볼 수 있다.
이론적으로는 이미 기 구축된 SSL/TLS 연결 내에서 새로운 handshake를 수행할 수 있으며, 실제적으로도 수행되며 일어나고 있다. 이를 수행하기 위해 서버는 SSL/TLS가 구축된 환경 내 아무때나 HelloRequest를 보내고 클라이언트는 ClientHello를 보내면 된다. 전형적은 흐름은 다음과 같다.
이 과정에서 약간의 취약점이 있는데 이를 간략하게 설명한다면, 일반적으로 SSL/TLS 보안성을 “forward” 측면에서만 활용한다. 새로운 handshake를 수행할 때, 이전 연결에서 유효한 클라이언트에 관한 모든 것들은 새로운 handshake 이후에도 계속 유효해야 하지만 그 반대는 아니다. (이말인즉, 이후 생성된 SSL/TLS 연결에서 교환된 정보는 이전 생성된 SSL/TLS 연결에서는 유효하지 않다는 얘기이다.) 어쨋든 위 상황에서 첫 번째 요청(request)은 두 번째 생성된 SSL/TLS 연결(인증서 기반 연결)에서 보호되지 않는다. 이 점을 공격자가 노린다.
Alert 메시지는 경고나 에러 메시지를 보낼 때 사용한다. 이 메시지중 close_notify 메시지가 중요하다. 이 메시지는 서버나 클라이언트가 연결을 끊고자 할 때 보내는 메시지이다. 해당 메시지를 서버나 클라이언트가 받으면 해당 메시지에 대한 응답을 해줘야 하고 해당 연결을 끊도록 해야 한다. 하지만 해당 세션은 abbreviated handshake로 재 연결을 하기 위해 계속 유효하다. 이 메세지는 다른 레코드들 처럼 암호화 기법으로 보호되어 있어 공격자에 의해 접근하기 힘들다. 참고로 오래된 HTTP에서의 SSLv2는 close_notify 없이 SSL/TLS 연결을 끊을 수 있도록 되어 있어서 공격자들이 이를 이용했었다. 현재는 대부분의 HTTP 서버들이 Content-Length나 chunked encoding을 사용하므로 유효하지 않다.
-------------------------------------
https://lesstif.gitbooks.io/web-service-hardening/content/ssl-tls-https.html
Creating a KeyStore in JKS Format
https://docs.oracle.com/cd/E19509-01/820-3503/ggfen/
Java 2-way TLS/SSL (Client Certificates) and PKCS12 vs JKS KeyStores
-----------------------------------------
--------------------------------------------
| ffmpeg 사용해서 mp4, aac 등 합치기 (0) | 2018.06.07 |
|---|---|
| Windows 7 command (0) | 2017.11.09 |
| windows 10 에서 wmencoder64 설치 (0) | 2017.01.01 |
| windows 10 최적화 (0) | 2016.12.19 |
| 윈도우 10 Windows 10 기본 프로그램 (기본 앱) 삭제 제거 하는 방법 (0) | 2016.12.19 |
