Merge pull request #19 from HyunJunSon/main

이미지주소변경

_posts/2023-11-15-Https.md

@@ -4,7 +4,7 @@ title: Https 누구냐 넌?
 author: 손현준
 categories: 기술세미나
 banner:
-  image: https://github.com/Kernel360/blog-image/blob/main/2023/1115/1.jpg?raw=true
+  image: https://raw.githubuserconten.com/Kernel360/blog-image/main/2023/1115/1.png  
   background: "#000"
   height: "100vh"
   min_height: "38vh"
@@ -19,7 +19,7 @@ HTTPS는 인터넷을 통한 안전한 데이터 전송에 사용되는 보안 
 
 
 ## 1. Https 란?
-![참고자료2](https://github.com/Kernel360/blog-image/blob/main/2023/1115/2.jpg?raw=true)
+![참고자료2](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/2.png)
 
 우리가 인터넷에서 자주 사용하는 인터넷 주소를 살펴보면, 프로토콜, 호스트(도메인), 포트번호, 경로, 쿼리값 등으로 이루어져 있습니다. 이 중 가장 앞부분에 
 
@@ -29,16 +29,16 @@ HTTPS는 인터넷을 통한 안전한 데이터 전송에 사용되는 보안 
 
 의미한다고 보면 됩니다.
 
-![참고자료3](https://github.com/Kernel360/blog-image/blob/main/2023/1115/3.jpg?raw=true)
+![참고자료3](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/3.png)
 
 ## 2. Https 와 Http 의 차이점?
-![참고자료4](https://github.com/Kernel360/blog-image/blob/main/2023/1115/4.jpg?raw=true)
+![참고자료4](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/4.png)
 
 Http 와 Https에는 위 표와 같은 차이점이 존재합니다. Https는 장점만 존재하지는 않습니다. Http 보다 추가적인 보안과정이 필요하므로, Http보다는 느릴수 
 
 밖에 없습니다. 따라서, 특별한 보안이 필요하지 않는, 사내망이나, 인트라넷의 경우는 Https를 하는것이 오히려 더 부적절 할 수 있습니다.
 
-![참고자료5](https://github.com/Kernel360/blog-image/blob/main/2023/1115/5.jpg?raw=true)
+![참고자료5](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/5.png)
 
 Https는 왜 그림과 같이 SSL 이나, TLS 과정이 포함됩니다. SSL은 Secure Sockets Layer의 약자로 인터넷 연결을 안전하게 유지해 주고, 두 시스템 간에 
 
@@ -49,7 +49,7 @@ Transport Layer Security의 약자로, SSL보다 더 안전한 업데이트 버
 ## 3. Http 의 문제점과 해결책
 
 ### 문제점1. 내가 접속한 사이트가 진짜 사이트인지 판단 할 수 없다.
-![참고자료6](https://github.com/Kernel360/blog-image/blob/main/2023/1115/6.jpg?raw=true)
+![참고자료6](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/6.png)
 
 
 Https를 사용하지 않으면, 내가 지금 접속하여 통신하고 있는 서버가 진짜, 서버인지 가짜 서버인지 확인할 수 있는 방법이 없다. 이는 사람들에을 피싱사이트로 유도
@@ -58,13 +58,13 @@ Https를 사용하지 않으면, 내가 지금 접속하여 통신하고 있는
 ### 해결책1. CA (Certificate Association)
 CA 는 인증기관으로, 웹사이트, 이메일주소, 회사 또는 개인같은 엔티티의 신원을 확인하고 전자 문서를 발행하여 암호화 키에 바인딩하는 회사 또는 조직을 말한다.
 CA의 인증은 내가 통신하고 있는 주체에 대한 신뢰성을 부여한다.
-![참고자료7](https://github.com/Kernel360/blog-image/blob/main/2023/1115/7.jpg?raw=true)
+![참고자료7](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/7.png)
 
 
 위와 같이 CA의 인증을 받은 사이트의 경우는, 인증서를 확인할 수 있다.
 
 ### 문제점2. 클라이언트와 서버가 주고 받는 정보를 제3자가 볼 수 있다.
-![참고자료8](https://github.com/Kernel360/blog-image/blob/main/2023/1115/8.jpg?raw=true)
+![참고자료8](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/8.png)
 
 Https 환경이 아니면, 보안측면에서 주고 받는 데이터에 대한 암호화가 되지 않아, 클라이언트와 서버간의 주고 받는 데이터를 제3가 탈취할 수 있다는 
 위험성이 생긴다.
@@ -73,7 +73,7 @@ Https 환경이 아니면, 보안측면에서 주고 받는 데이터에 대한
 
 데이터 탈취에 대한 위험성을 줄이기 위한 해결책으로 암호화를 생각해 볼수 있다. 암호화는 크게 두가지 방식을 생각해 볼 수 있는데, 대칭키 방식과 비대칭키 방식이 
 있다.
-![참고자료9](https://github.com/Kernel360/blog-image/blob/main/2023/1115/9.jpg?raw=true)
+![참고자료9](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/9.png)
 
 ## 4. Https 의 내부작동원리
 
@@ -82,25 +82,25 @@ Https 환경이 아니면, 보안측면에서 주고 받는 데이터에 대한
 
 
 ### 대칭키의 한계
-![참고자료10](https://github.com/Kernel360/blog-image/blob/main/2023/1115/10.jpg?raw=true)
+![참고자료10](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/10.png)
 
 대칭키는 하나의 키로 암호화와 복호화를 모두 진행한다. 따라서, 본질적으로 제3자(해커) 몰래 대칭키를 어떻게 나누어 가질 것인가 라는 문제에 부딪친다.
 따라서, 이에 대안으로 등장한 것이 비대칭키 이다. 비대칭키는 공개키와 개인키 두개로 각각 암호화와 복호화의 하나의 기능만 하도록 만들었다.
 
-![참고자료11](https://github.com/Kernel360/blog-image/blob/main/2023/1115/11.jpg?raw=true)
+![참고자료11](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/11.png)
 
 
 비대칭키를 교환하는 방식은 위와 같다.
 
-![참고자료12](https://github.com/Kernel360/blog-image/blob/main/2023/1115/12.jpg?raw=true)
+![참고자료12](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/12.png)
 
 
 1. 클라이언트와 서버 각 사이드가 공개키와 개인키 각각의 키쌍을 생성합니다.
 2. 각 사이드의 public 키를 교환합니다. 이 public 키는 전세계 모든 컴퓨터에게 개방되어 있고 용도는 암호화 입니다.
 3. 받은 상대방의 public키로 평문을 암호화 하고, 암호화된 암호문을 상대방에게 보냅니다.
 4. 받은 암호문을 개인키로 복호화 합니다.
 
-![참고자료13](https://github.com/Kernel360/blog-image/blob/main/2023/1115/13.jpg?raw=true)
+![참고자료13](https://raw.githubusercontent.com/Kernel360/blog-image/main/2023/1115/13.png)
 
 
 ---