리눅스, 우분투?
아파치(HTTP 웹 서버)
웹서버 >> 웹 브라우저와 같은 클라로부터 http 요청을 받아들이고, html문서와 같은 웹페이지를 반환하는 컴퓨터 프로그램.
주된 기능 >> 웹페이지를 클라이언트에게 정적 정보 전달(html, css, js, image)
웹서버는 동적,정적 방식 2가지로 나뉨
정적 웹서버 : 단순 html 문서만을 사용자에게 제공 -> 아파치 웹서버 하나만 됨.
동적 웹서버 : 사용자의 요구에 따라 다양한 웹페이지 제공. 이를 위해 php, mysql 데이터 베이스 연계하여 사용. (APM. 리눅스에선 LAMP라함.)정적 데이터처리
웹서버용 소프트웨어,http 아파치 서버로 불림.
아파치는 많은 운영체제에서 운용가능(리눅스, 윈도우 등등)
구축이 쉽다
(무겁고 취약점이 몇 있어 대형사이트 운영자는 Nginx를 사용함)
무료라 중소에서 사용.
톰캣
동적인 데이터 처리하는 웹서버
WAS(web application server)라고 불림.
DB와 연결되어 데이터를 주고받음.
리눅스의 배포판이 우분투.
우분투의 뿌리 리눅스
ipconfig에서 나오는 주소 ? 윈도우에서 사용.공유기에 속한 네트워크. 공유기가 나의 공인ip를가지고 쪼개는 원리로 생각.내부ip(실제 내컴의 주소)
ifconfig에서 나오는 주소 ? 유닉스계열에서 사용.
네이버에서 내 IP주소 확인으로 나오는 주소 ? (외부)공인ip (naver검색해서 나온거로,실제 내 컴의 주소는 아님)
ubuntu 버전 확인하는 법 >> lsb_release -a
(20.04 사용중)
sudo apt-get update -y
kill -9
/etc란 ?
ubuntu에 netstat 명령어 >>
netstat -l
netstat -tnlp (-nltp든 뭐든 순서바껴도 노상관) LISTEN 중인 포트 정보 표시
ps -aef | grep apache2
ip : 통신 프로토콜
ip주소 : 주소
ipv4 40억여개 정도만 커버가능 : 1옥텟으로 4부분 => 8bit로 4부분 총 32비트
ipv6 위 방법이 고갈된 상태라 생겨남. 2옥텟 8부분으로 :(콜론) 구분
클래스
ejs 빌드하는 법
ip주소가 바껴도
login id 는 동일
load를 해야함.
putty
npx babel src -d dist 명령어로 build완료
Address already in use 에러
해결 : netstat -tulpn | grep 3000 명령어로 맨마지막 넘버 확인
ex) 4862/node << 4862가 port 넘버
kill -9 4862g
FileZila : FTP프로그램
내 컴퓨터에 있는 파일들을 FTP서버에 옮기기위한 프로그램
대표적으로 파일질라
웹호스팅이나, 이미지호스팅,홈페이지 제작, 프로그래밍 등.
FTP?
File Transfer Protocol
TIP/IP 네트워크상의 장치가 파일을 전송할 떄 사용하는 규약
20번 포트 : 데이터 전달
21번 포트 : 명령어 전달
SFTP?
ftp에 암호화(ssh)개념이 추가되어, 네트워크 레벨에서의 정보유출을 방지하는 프로토콜
22번 포트 사용
vscode에서 저장한 순간 filezila 프로그램에도 자동저장 되는 시스템?
openssl은 뭔가? 왜 만들라고 한건가?
11.3 카페에서 나눈 이야기 정리
https:// <<< openssl로 인증서 발급한걸 이용해야한다 : 기본포트 443
http:// 기본포트 80 << 카메라같은게 당연히 안된다.
이러닝에서 차시차시 몇차시는 메타버스를 접목 시킬건다.
메시방식을 통해 webrtc를 일단 메커니즘을 파악하고
미디어서버를 이용한 SFU방식으로 3사람 이상의 통신을 하게된다.
이미 만들어져있는 것이 있어 분석할 순 있지만 내가 알아서 처음부터 리액트로 만들어볼 수 도 있다.
자바스크립트로 되어 있는 것을 그대로 리액트로 바꾸면 된다.
상장되어있지만, 둘다..
버넥트 년 100억씩 잃고 있다.
컴투버스 1달만에 폭망
레오님 방식 레버리지 채찍질
홍알 방식 맨주먹
내가 해봐야할것들
openssl 인증서 발급받은 것을 이용해서 https:// 를 가능케 하라.
:qa!
라하면 우분투에서 나올 수 있음
access denied, permission denied같은거 나오면 >> 맨앞에 sudo를 붙여보시길
(root 권한을 갖게해줌)
HTTP에 SSL 적용을 하여 Https 통신을 하게된다!
!!! ❤️❤️❤️ 지금 문제(11.3 해결)
내가 받은 인증서가 올바르게 받은 인증서인지 확인.
C:\Users\YMX 이 경로안에 보안인증서 3개가 있음
rootCA, rsa_rootCA, server
key값 확인
openssl rsa -in rsa_rootca.key -text 명령어로
rootCA.key 확인됨.
server.key 확인됨.
rsa_rootca.key 확인됨.
csr
crt 확인(key, csr이 있어야 확인할 수 있으니 csr이 있음을 방증함)
key,csr은 있는데 crt는 왜 없누?(보안인증서가 crt였음!!!)
openssl x509 -in server.crt -noout -text
자 이제 https로 연결 시키자!
어떻게???
클라와 서버간 통신을 제3자가 보증해주는 전자화된 문서
let's encrypt가 제 3자. 즉 CA(certifcate authority) 인증기관.
SSL 인증서에는 아래 2개가 들어가있음
1. 서버 공개키
2. 서비스의 정보
클라가 서버에 접속한 직후 서버는 클라에게 이 인증서 정보를 전다.
클라는 이 인증서 정보고 신뢰할 수 있는것인지 검증 후 다음 절차 수행.
SSL 인증서는 공개키와 개인키 쌍을 가짐.
SSL의 통신 과정
1. 핸드 셰이킹
2. 세션
3. 세션 종료
1번째 : TCP 연결
SSL은 TCP방식으로 TCP 3 way hand shaking으로 TCP연결이 만들어지면 SSL 핸드셰이크가 시작됨
2번쨰 : 클라이언트 헬로 메세지
클라가 서버로 헬로 메세지를 전송하면서 hand shake를 시작
이 메세지에는 클라가 지원하는 SSL, TLS버전, 지원하는 암호화 알고리즘의 목록과 랜덤한 바이트 문자열을 보냄.
3번째 : 서버 헬로메세지
서버가 클라에게 헬로 메세지 전송.(즉, 응답이라 봄)
서버는 클라가 지원하는 암호화 알고리즘 목록에서 한가지를 선택하고,
서버의 SSL인증서, 그리고 서버에서 생성한 또 다른 무작위 바이트 문자열을 모두 담아 클라에게 전송.
(선택 알고리즘, SSL인증서, 무작위 문자열 전송)
4번째 : 인증과 예비 마스터 암호
이를 통해 서버가 인증서에 명시된 서버인지, 클라가 상호작용중인 서버가 실제 해당 도메인의 소유자인지를 확인.
클라가 서버의 ssl인증서를 인증서 내장된 CA(발행기관)리스트를 통해 검증한다.
만약 CA리스트에 인증서가 없다면 사용자에게 경고메세지를 출력.
인증서가 CA에 의해 발급된 것인지 확인을 위해 클라에 내장된 CA의 공개키를 이용해서 인증서를 복호화한다.
복호환에 성공한다면 인증서는 CA의 개인키로 암호화된 문서임이 보증된것.
왜냐면 CA의 개인키로 암호화된것을 CA 공개키로 복호화 했기 때문.
클라는 SSL인증서를 통해 서버의 공개키를 알아낸다.
이제 PMS(pre master secret)생성
PMS는 서버의 무작위 바이트문자열 & 클라의 무작위 바이트 문자열로 조합해서 만듬.
PMS는 서버의 공개키를 통해 암호화되어 서버에 전달.
PMS는 이후에 세션 단계에서 암호화하기 우해 사용할 것이며 암호화 기법이 대칭키이므로 절대 노출되선 안됨.
5번째 : 서버의 개인 키 사용
클라는 서버의 공개키로 암호화된 PMS를 서버로 보냄.
서버는 자신의 개인키를 사용해 PMS를 복호화.
이제 서버와 클라는 PMS를 공유하게 됨.
6번째 : 세션 키 생성
서버와 클라는 일련의 과정(SSL 표준에 지정된 키 유도함수)를 거쳐 PMS를 master secret 값으로 만듬.
그리고 master secret을 사용해 session key를 만듬
7번쨰 : 클라, 서버 준비 완료 후 안전한 대칭 암호화 성공
클라가 세션키로 암호화된 완료메세지를 보내고, 서버가 세션키로 암호환된 완료 메세지를 보낸다.
핸드 셰이킹 -> 세션 단계
세션은 실제로 서버와 클라가 데이터를 주고 받는 단계.
이 단계에서 핵심은 정보를 상대방에게 전송하기 전에 세션 키 값을 이용해서 대칭키 방식으로 암호화 한다는 점.
암호화된 정보는 상대에게 전송되고, 상대방도 세션키 값을 알고 있기 떄문에 암호를 복호화 할 수 있다.
대칭키 사용 이유
공개키(비대칭키) 방식은 많은 비용이 발생.
트래픽이 많은 서버일수록 많은 지불을 하게됨.
반대로 대칭키는 암호를 푸는 열쇠인 대칭키를 상대에게 전송해야 하는데, 암호화가 되지 않은 인터넷을 통해 키를 전송하는 것은 위험함.
따라서 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고, 실제 데이터를 주고 받을 떄는 대칭키를 이용한다.
마지막 세션 종료 단계는 데이터의 전송이 끝나면 SSL통신이 끝났음을 서로에게 알려주고 대칭 키인 세션 키를 폐기함.