1 00:00:00,220 --> 00:00:08,250 ‫HTP Hypertext Transfer Protocol is an application protocol, hypertext is structured text that uses 2 00:00:08,250 --> 00:00:16,350 ‫logical links between nodes containing text and HTTP is the protocol to exchange or transfer hypertext. 3 00:00:16,860 --> 00:00:19,590 ‫HTTP is a stateless protocol. 4 00:00:19,650 --> 00:00:24,660 ‫That means no information is retained by either sender or receiver. 5 00:00:25,440 --> 00:00:31,590 ‫HTTP functions as a request response protocol in the client server computing model. 6 00:00:31,980 --> 00:00:36,540 ‫A web browser, for example, may be the client and an application running on a computer. 7 00:00:36,540 --> 00:00:38,820 ‫Hosting a website may be the server. 8 00:00:38,850 --> 00:00:42,450 ‫The client submit an HTTP request message to the server. 9 00:00:42,480 --> 00:00:48,840 ‫The server, which provides resources such as email files and other content, returns a response message 10 00:00:48,840 --> 00:00:49,500 ‫to the client. 11 00:00:49,590 --> 00:00:55,350 ‫The response contains completion status information about the request and may also contain requested 12 00:00:55,350 --> 00:00:57,150 ‫content in its message body. 13 00:00:57,930 --> 00:01:05,580 ‫The most used HTTP request is get a get request is designed to request server resources. 14 00:01:06,480 --> 00:01:12,360 ‫Were these types of requests, the parameters are sent to the server inside the U R L. 15 00:01:13,480 --> 00:01:17,800 ‫You see two different H.M. elements which will cause get requests. 16 00:01:18,940 --> 00:01:24,700 ‫Post request is designed to request server resources as well as get request. 17 00:01:25,390 --> 00:01:33,100 ‫But unlike get requests, parameters are sent to the server inside the body of the request instead of 18 00:01:33,100 --> 00:01:33,760 ‫the URL. 19 00:01:33,910 --> 00:01:40,570 ‫It's still possible to send the parameters inside the URL, but if you use post request, you should 20 00:01:40,570 --> 00:01:44,030 ‫prefer sending parameters inside the body the URL. 21 00:01:44,320 --> 00:01:48,250 ‫In this slide, you see the HTML elements to send a post request. 22 00:01:48,340 --> 00:01:49,300 ‫What's that you ask? 23 00:01:49,480 --> 00:01:54,430 ‫What's the advantage of sending parameters inside the body instead of a URL? 24 00:01:54,640 --> 00:01:55,420 ‫Good question. 25 00:01:56,110 --> 00:02:01,960 ‫Almost always, the traffic between the server and the client is logged on the server side. 26 00:02:02,740 --> 00:02:05,980 ‫Such log files usually contain the URL. 27 00:02:07,090 --> 00:02:12,790 ‫If you send the parameters in your URL, they are saved as clear text in your log files. 28 00:02:13,000 --> 00:02:18,700 ‫So anyone who can see the log files can also see your sensitive parameters. 29 00:02:19,120 --> 00:02:26,110 ‫You should use post requests to send sensitive data, but please make a note that it's not enough for 30 00:02:26,110 --> 00:02:33,190 ‫the privacy of the traffic because any man in the middle who listens to the network will see the parameters 31 00:02:33,550 --> 00:02:39,640 ‫even though they're inside the body of the request message, so you should encrypt your traffic. 32 00:02:40,180 --> 00:02:46,720 ‫The server, which provides resources such as HTML files and other content, returns a response message 33 00:02:46,720 --> 00:02:47,380 ‫to the client. 34 00:02:47,410 --> 00:02:53,590 ‫The response contains completion status information about the request and may also contain requested 35 00:02:53,590 --> 00:02:55,450 ‫content in its message body. 36 00:02:55,450 --> 00:02:59,080 ‫Every response has three-digit response status codes. 37 00:02:59,080 --> 00:03:03,460 ‫Responses with a code starting with one are informational responses. 38 00:03:03,460 --> 00:03:10,060 ‫An informational response indicates that the request was received and understood it is issued on a provisional 39 00:03:10,060 --> 00:03:12,970 ‫basis, while request processing continues. 40 00:03:13,000 --> 00:03:16,030 ‫It alerts the client to wait for a final response. 41 00:03:16,090 --> 00:03:22,810 ‫The message consists only of the status line and optional header fields and is terminated by an empty 42 00:03:22,810 --> 00:03:23,230 ‫line. 43 00:03:23,740 --> 00:03:27,230 ‫Responses with the code starting with two means success. 44 00:03:27,250 --> 00:03:34,090 ‫This class of status code indicates the action requested by the client was received, understood, accepted 45 00:03:34,390 --> 00:03:36,520 ‫and processed successfully. 46 00:03:37,150 --> 00:03:40,900 ‫Responses with the code starting with three mean redirection. 47 00:03:40,930 --> 00:03:46,210 ‫This class of status code indicates the client must take additional action to complete the request. 48 00:03:46,240 --> 00:03:52,810 ‫Many of these status codes are used in URL redirection, a response with the code starting with four 49 00:03:52,840 --> 00:03:56,800 ‫shows that there is an error that seems to have been caused by the client. 50 00:03:57,010 --> 00:04:02,830 ‫For example, if the requested resource is not found on the server, you get a 4x x coded response. 51 00:04:03,370 --> 00:04:10,000 ‫Five x x coded responses mean that the server failed to fulfill an apparently valid request. 52 00:04:10,870 --> 00:04:20,110 ‫HTTPS consists of communication over HTTP within a connection encrypted by TLS transport layer security 53 00:04:20,380 --> 00:04:23,830 ‫or its predecessor, SSL Secure Sockets layer. 54 00:04:24,250 --> 00:04:32,290 ‫The main motivation for HTTPS is authentication of the visited website and protection of the privacy 55 00:04:32,290 --> 00:04:35,020 ‫and integrity of the exchanged data. 56 00:04:35,680 --> 00:04:40,090 ‫There are a few questions we should ask about using SSL or TLS. 57 00:04:40,390 --> 00:04:44,480 ‫Does the application have a version working without SSL? 58 00:04:44,500 --> 00:04:52,600 ‫If it has, the user might be tricked to connect over http, or an attacker can perform an SSL strep 59 00:04:52,600 --> 00:04:58,060 ‫attack to turn an HTTPS connection into an HTTP connection. 60 00:04:59,260 --> 00:05:03,250 ‫Which versions of SSL or TLS are allowed by the server? 61 00:05:03,640 --> 00:05:10,120 ‫The older versions of SSL and TLS have weaknesses, so it's not safe to use them as a certificate of 62 00:05:10,120 --> 00:05:16,350 ‫the application been signed by a valid certificate authority, which algorithms are used for encryption 63 00:05:16,360 --> 00:05:17,530 ‫and are they strong enough? 64 00:05:17,980 --> 00:05:26,200 ‫There are tools such as SSL scan and SSL Digger to test the SSL or TLS configuration of the server. 65 00:05:26,860 --> 00:05:29,350 ‫You can find the tools in Kali Linux. 66 00:05:30,070 --> 00:05:35,320 ‫In addition, there are some browser plugins to analyze the SSL or TLS of the application. 67 00:05:35,650 --> 00:05:42,970 ‫You can try Calomel or Comodo SSL plugins for Firefox, so even though it might seem a bit off topic, 68 00:05:42,970 --> 00:05:49,270 ‫we can quickly see how a typical encrypted connection between the server and the client is established. 69 00:05:49,960 --> 00:05:55,480 ‫The client sends the information that the server needs to communicate with a client using SSL. 70 00:05:55,510 --> 00:06:01,540 ‫This information contains a client's SSL version number cipher settings session specific data. 71 00:06:02,540 --> 00:06:08,270 ‫The server sends the information that the client needs to communicate with the server over SSL server 72 00:06:08,300 --> 00:06:10,120 ‫also sends its own certificate. 73 00:06:10,130 --> 00:06:15,830 ‫The client uses the information sent by the server to authenticate the server using all data generated 74 00:06:15,830 --> 00:06:17,300 ‫in the handshake thus far. 75 00:06:17,330 --> 00:06:23,150 ‫The client creates the pre master secret for the session, encrypts it with the servers public key, 76 00:06:23,360 --> 00:06:26,960 ‫and then sends the encrypted pre master secret to the server. 77 00:06:28,040 --> 00:06:34,490 ‫The server uses its private key to decrypt the pre master secret, and both the client and the server 78 00:06:34,490 --> 00:06:37,940 ‫perform a series of steps to generate the master secret. 79 00:06:37,970 --> 00:06:43,790 ‫Then they use the master secret to generate the session keys, which are symmetric keys used to encrypt 80 00:06:43,790 --> 00:06:51,050 ‫and decrypt information exchanged during the SSL session and to verify its integrity. 81 00:06:51,860 --> 00:06:57,380 ‫The client then sends a separate message indicating that the client portion of the handshake is finished. 82 00:06:57,530 --> 00:07:02,600 ‫The server sends a separate message indicating that the server portion of the handshake is finished.