 So we all use web browsing as a primary internet application, so one thing we know is that the protocol that it uses to talk between browser and server is HTTP. We're going to look at how can we make that more secure when we're sending data between browser and server so that people in the middle cannot intercept so that when we contact a web server, we're sure it's the web server that we want to talk to and in the next topic so that you can develop applications, web applications that are unlikely to be compromised. So before we talk about web security, I'll just give a reminder about what we know about web browsing and web applications. And this will be quite quick because I know you all know this. We can think of web browsing as an application where we talk between a web browser application, the software and a web server, which is also software. And we use the protocol HTTP, the hypertext transfer protocol to communicate. So the user is, well in fact the user of the web browser clicks on a link or types in a URL in the address bar and that triggers the browser to communicate with the web server. A normal case is to request a web page which someone's already put on the web server and when that request comes to the web server, the web server responds with that web page and it's seen on our browser. So we can think of the browser and the server as a piece of software that we run on computers in the internet and they're different. Because you know there are different web browsers, there are also different web server applications. A patchy web server you may have seen and we've seen in the lab but there are others as well. A little bit more detail at the protocol level, HTTP is a request response protocol, the browser sends one request, the server sends one corresponding response. It's always one request, one response. We don't send a request for a web page and then the server sends back three responses, one containing the web page, one the others containing images. That's not how it works. We request a web page, the server sends back the web page. If there's some images to download then we send another request for each image and each image comes back in the responses. Some addressing that's important when we're web browsing is we use transport, the transport protocol of TCP, the transmission control protocol and that uses port numbers to identify which application is communicating so the browser when it initiates a connection, the operating system assigns the browser a port number so that will change, it's a dynamic port number and the server typically uses a fixed or a well-known port number and that's port number, our web server, which port number, 80, our web server normally uses port 80. It can use a different port number but that makes it harder for the user, the web browser because they must know that different one. By default the browser will assume the server is using port 80 and of course to send a packet between the computer using the browser and server we need to know the IP addresses of them. So we'll assume that the browser knows the IP address of the server, they assume that the port number is 80, therefore they can create an IP datagram with the destination address of being that of the server and the destination port being 80 and that packet will be delivered across the internet to the correct server and eventually to the web server application which will send a response. A little bit about HTTP, it's a request response protocol. We say it's stateless in that the simplest way that we use HTTP is that we send a request to the web server for a resource, the server sends a response for that request, the next request for a resource to the web server, the web server doesn't maintain any state about what happened from the previous request. If you can think from the server's perspective, every request it receives it treats independent of what's happened in the past. It doesn't maintain any state about the past requests and responses it sent. So it makes the server very simple. Receive a request, handle that request only, send a response. If you receive another request from the same web browser, you don't care that you've received previous ones, you just handle that one request you've received and send back a response. The implementation of HTTP doesn't maintain any state information between subsequent requests. It makes the protocol very simple and the server simple to implement, but it means that using HTTP there's no way to maintain some information about what's happening in terms of the relationship between different requests. We'll see later when people develop web applications, they introduce other ways to maintain some state information. That will become important, especially when we look at the next topic of web applications and application attacks. So the web browser, the client is formally referred to as a user agent that sends a request and the server sends the response message, port number 80. A HTTP message is a text message, so it consists of a number of lines and the generic format is that there's a start line, the first line which has some structure, there's some optional header lines, so we may include some extra information in the request or the response and then we may have an empty line, nothing on it, followed by an optional message body, especially in a response, the message body will be the web page that we're sending back. The start line differs in the request and response and the header format is similar in the request and response, we always have a field name followed by a value, like the header field and the actual value of that. Just showing an example that if we, in the web browser will not go through on the actual web browser, but at point one the user types in a URL into the address bar, HTTP call on slash slash abc.com slash test slash index dot HTML and they press send or enter to trigger the browser to request that. So the browser uses the domain name of the server, abc.com to find the corresponding IP address of the server and sends a HTTP request and the common format of the request we'll see is called a get request, we want to get a resource, get a file in this case and we send a request for that resource to the web server, when the web server receives that request they look inside their web directory if that file exists, so there will be a special directory on the server that stores all the web pages, if it's there and everything's working correctly then the web server will read that web page and send the content of that index dot HTML back in the response and the response will include a start line, in this case the header fields are not shown, an empty line followed by the content of the file. When the browser receives the response at point three it checks the response, it's okay and then takes the content and uses that to display something on the screen, to display the web page. If there was a link or a reference to an image inside this web page, so the image, the img tag or maybe a reference to a style sheet, css files or other objects then what your browser would normally do when it sees those references to other objects it would create subsequent requests, request the image, get the image back and then it's displayed on your screen, request the style sheet, get the style sheet back and then the style is applied to the web page, sometimes you may even see that happening, you visit a website and the images gradually load, that's because you've received the web page back but then the requests are coming for the images, so it takes some time before those images come back and are loaded on the web page, so the browser loads the page and then eventually loads in the images. The request messages, the start line is made up of three values, the method that we're using to request the URL, the path and file name that we're requesting, the resource and the version of the protocol we're using, the method, the common method we'll see is get, we want to get a resource but there are others, another one we may see in later examples, in later examples is post, post is used when for example you fill in a form on a web page and you press the submit button on that form that triggers usually the web browser to send a post message to the server and inside that post message contains the values of the form fields that you filled in, this is really like sending data to the server and asking the server to process that and there are other fields or other methods. The URL is the page that we're accessing and the version is usually HTTP 1.0 or 1.1. The response messages again have a start line with three values, the version same as before, the status code and status reason, so the status code and status reason go together and the status code is a number and the reason is just a short description, so for example we'll often see 200 okay meaning your request was successful or maybe you'll see 404 not found, the resource you requested is not available and there are many other status codes and there are optional headers that may be included in the requests and the responses and this is just some of the headers that you may see, the date and time, what character sets or encodings we're willing to accept, maybe if there's some login, we submit a username and password to the server, there may be an authorization field containing those usernames and passwords, something identifying the web browser, the type of content, the length of content and there are many other fields, so just some that we may see in some examples, so just a quick introduction to HTTP just so that when we give some examples you'll be able to follow along, it's not so much that you need to understand and remember the details of how HTTP works but when we see it from a security perspective you should understand what's happening there, so web browsing uses HTTP, we send a request, we get a response, who has created a web application, everyone here I'm sure has created web applications maybe with your database course last semester with Dr. Tanarak, you had to create a web application, correct? Any other courses? Lab maybe? No? Lab with this semester or last semester? Last semester, okay, so your experts are creating web applications, what technologies did you use to create a web application? PHP, HTML, okay, so the basic thing for a web application, the simple web applications are just really a set of HTML pages files, so you could create a website by just writing some HTML text files with a syntax of HTML and that could be a simple application but I think you know that to make your application more dynamic so that the content can change depending on what the user is doing, you may use other languages like PHP to add some dynamic operations to your website, so let's just recap on what you know about web applications because again when we look at some attacks on web applications this knowledge is necessary, so a simple website is made up of plain static web pages, HTML, images, other files, maybe style sheets, whatever other resources are needed but many applications need some dynamic or use some dynamic content, so what we mean by that is that the content served, not server, served, the content sent back from the server will change depending upon the request, that is we request a file for a static web page then that file if we request say index.html that same file will always be sent back whenever someone requests that index.html, the same file, the same content is always sent back but with a dynamic website maybe we request index.php and what the server does it may change the content that's sent back depending upon who's making the request and what they've done in the past that's what I mean by dynamic content, the content sent back may change even if it's requesting the same resource, so it provides some interactivity that is it feels like the user things are changing and especially tailored content so as you know someone can log in to a website and when two different people visit the same page they'll see different content specific for them tailored for the user. There are different technologies to provide this dynamic content that can be done client side or server side or a combination client side uses for example the content that's sent back to the browser the browser then interprets the code in that content to do something like javascript, flash, silverlight and others for example flash content you request a flash object the server sends back the flash object and your web browser plays that video or object whatever it is. Server side is I think what you have spent some time on is that you send a request for web page the server processes that request and for example with php executes some code and that creates the content that is sent back and again there are many different technologies for what the server can use to execute as php many others and to make it easier the content rather than storing in html files is usually stored in databases so there'll have to be a combination between the server side processing and the database in that the say the php code will execute a query on the database to grab some content and then send that back so we can think of it like this in that the web browser still sends a HTTP request the communication between browser and server doesn't change still send a request get a response but with dynamic websites what we have is we can think the web server when it receives a request the web server is configured if that request is a resource of a particular type for example if the request is for index.php the web server is configured to say ah this is a php file that they're requesting I will not send back the php file what I'll do is I'll get the php software to execute that file on the server so I say the engine there executes the code and the execution of the code may create some content that is then sent back to the server and the server takes the content and sends it back in the HTTP response and often the execution of that code will also include a query to a database an SQL query for example to grab some information from the database so I think you've had experience you've written web pages probably using php the the engine is php the the software that executes that php and the database you used was what database server MySQL so you've written some SQL queries that inside your php code that will grab some information from the database or put information into the database insert into the database so up until now I think most of this is not new to you what we are interested in is some of the security issues with doing all of this how do we make our web application secure and there are a number of different issues first the request and response sent between browser and server they are sent across the internet how do we make sure that no one can see that content sent across the internet so encrypt is the answer so you know we need to encrypt well how do we encrypt and we'll see that HTTPS is really using normal HTTP using instead of TCP directly it uses another protocol the s is well it uses what was previously called SSL secure sockets layer but now the the latest version is called TLS transport layer security so HTTPS I think you know is used to make sure that the data sent between browser and server is encrypted so that someone on the internet here who maybe has access to the wi-fi access point or the routers on the path between your browser and server cannot see the content that you're requesting and not cannot see what's sent back in the response so we'll go through how HTTPS works in this topic another security issue which is important is when you're using your browser and you send a request to your bank website how do you know that your request actually goes to the web server of your bank not someone pretending to be your bank's website so what may happen is you send the request to your bank and someone in the internet a malicious user here intercepts that request and and sends it to a fake bank website and sends back a response and makes you think that you're accessing your bank website but you're actually accessing a malicious website and then they grab your username and password and steal all your money so the issue there is how does your browser know that the server you're communicating with is the real server and we'll see the method that's commonly used is to use digital certificates which combines well uses public key encryption public key cryptography so we'll go through them as well from so that's a form of authentication you need to authenticate the server and from the other direction when you often log into websites how does the server know that the request it's receiving is from you and not someone pretending to be you how does the server know it's you well a common technique is to use passwords so when you log into facebook you have to enter in your username and password send that to the server and the server compares that to the registered username and password when you first created an account so that we'll not look into the details of that because we've looked at the issues with password based authentication one one thing that's needed to make that work with web applications because hgdp is stateless when we send a request containing a username and password the server sends back a response the next hgdp request we said the server is stateless it has no think the server has no memory of the previous request in hgdp so there are ways to make it stateful and the way that's commonly used is that when we send a request to the server we include some session information some unique values that when the server receives the request it knows that this request is from the user that logged in previously so that the user doesn't have to always log in so there's some form of session management and i think you've implemented that everyone implemented some login feature for your website with php okay you so you implemented some session management already there are different ways to do it cookies is is one thing that's related to that and we will see in the next topic on web attacks that there are some attacks against session management what else is a security issue that the server that what they do is what it's the actions that performs are appropriate that is you send a request to the server the server then often executes some code say some php code and maybe inserts data into a database or reads data from a database your web application must be coded such that some malicious user cannot send a request to your application and get your application to do something nasty like delete all the data from your database so we need some form of authentication to make sure that this user is allowed to do this and we need to code our application well so that it there are no bugs that make it such that someone can compromise our application and the last thing or one of the other things that we may cover in this course is that often the user may want to keep their actions private you may want to access a website and again not know that people or not let people in the internet know that you're accessing that website so staying anonymous in your web browsing is another issue and we will get a little bit of time to look at that in the last topic in this course so in this topic we'll look at htbs and digital certificates the next topic we'll look at some attacks on web applications on session management and trying to get the server to do something bad and in the last topics we'll look at a little bit on keeping anonymous any questions before we start the security aspect so first let's look at htbs again i think you've used it a lot how does it work really htbs is just using normal htdp send a request get a response but that request and response is encrypted using another protocol called the old version ssl which was i don't maybe it's not here secure sockets layer maybe it's on a later slide secure sockets layer secure sockets layer not slayer and the newer version so it's been updated is called transport layer security it's part of the transport layer and it provides security mechanisms at the transport layer so htbs is simply htdp using this other protocol some practical things when you tell your browser how do you tell your browser to use ssl or tls well you in the url you use the the scheme htbs as opposed to htdp and that triggers your browser to send a request using ssl now in in this lecture i will switch between ssl and tls there are some differences so the the earlier versions of ssl version one version two are no longer recommended i think version three is almost identical to tls so we'll often think of ssl and tls as being the same but there are some subtle differences between versions but we will not go into that it was originally called ssl and then changed to tls one thing that's different is that the web server to receive requests using ssl it listens on a different port than port 80 it uses port 443 and what this provides us is that when we send a request so a normal htdp get request which contains the page we're requesting the url that will be encrypted so the request will be encrypted so if someone intercepts the request they will not see which page you're requesting when the web server sends back the web page that will also be encrypted so someone who intercepts will not see the content of the web page that you're getting your viewing when you fill in a form on your browser like username and password and press log in that information is sent using a htdp request again that will be encrypted so if someone intercepts they will not see the username and password and other things related to supporting htdp cookies will be encrypted in fact the contents of the htdp header is encrypted so all of that information in the request and response is no longer viewable by someone who intercepts the idea that someone here in the internet that intercepts these packets will not be able to see the content of your request or reply so that provides confidentiality of your request and response authentication is provided in two approaches again we said that the browser wants to be sure that they're talking to the correct server they're not talking to a fake server so the server is authenticated using a certificate so we'll go through how that works digital certificates and that is used or sent using ssl the common way for the server to know that the person sending the request is the right person is to use normal username passwords so when you visit your bank website before you can do anything on your account you must prove that you are the person that holds that account by entering your username and password and submitting that to the bank web server which checks against the registered credentials and then allows you to access the account so that's that username and password that you submit is just usually sent in a HTTP request so the authentication of the server is done as part of an SSL and we'll see that the authentication of the client is done in the using HTTP here are the names SSL secure sockets layer and transport layer security so SSL version 3 and TLS are effectively the same the older versions of SSL now considered insecure and SSL or TLS provides security services encryption authentication key exchange to applications that use TCP so any application that uses TCP normally can make use of SSL to encrypt the data one way to view that if we draw a picture of the layered stack we can think in the normal mode the application the web browser uses HTTP and your web browser the web browser implements HTTP and when you click on a link or create a request it sends a request what transport protocol does your web browser use transport protocol TCP so the HTTP request is created sent to TCP and then IP and then eventually sent across the internet and in terms of implementation TCP and IP are usually part of your operating system so this is the normal HTTP your browser implements HTTP the way to create the request and handle the response the operating system implements TCP and IP so when you create a request the request is sent to TCP in the operating system with HTTPS your browser still creates a HTTP request but your browser implements another protocol so in this case when you click on a link or type in a URL a normal HTTP request is created for your browser the browser also then passes that request to secure Socket Slayer or TLS which does the encryption and all the other things necessary for the encryption and then passes those encrypted messages to TCP and TCP and IP send them across the internet so SSL is we normally think of implemented as part of the application the browser for example or that as a library that other applications can use what's an implementation of SSL that you know of some software that implements SSL you've all used it think of some of the software you've used in some of your earlier homeworks what was it open SSL not secure shell remember open SSL we did some things you created your keys you created a public key using the command open SSL on the command line open SSL we used it as a standalone application but really open SSL was built as a library open SSL is a common implementation of SSL that web browsers use and web servers so open SSL mainly is used as a library that is other applications use that to do the encryption to do the key generation and so on and there are other implementations as well so for example when you use the Apache web server the Apache web server handles the HTTP request receives the request and creates the response but Apache then uses open SSL to decrypt the request and to encrypt the response when it sends back in the same way that you used open SSL to to do encryption and decryption Apache does that but as a library it uses it and the difference from the server perspective is that also so that the server knows to use SSL with the different port numbers we will not go through details of all parts of SSL I'll show you the the concepts and then we'll go through just one example to illustrate SSL and use go away SSL is quite complex it supports many cryptographic operations so the this it supports encryption so it provides methods to encrypt data and decrypt but also things like key exchange to encrypt data we need a key to encrypt it with so the way for the the client and server to exchange to agree upon a key is supported by SSL and there are different methods for doing that so we think SSL sits on top of TCP so it can be used by any application that would normally use TCP web browsing email file downloads they can all make use of SSL and it's split into different parts so it's called different protocols from the bottom up SSL record protocol that's the part that does the encryption so when you have data to send this will encrypt it using the chosen algorithm you SSL doesn't specify which algorithms you must use it will let you choose for example AES RC4 and others so SSL record protocol is the part that does the encryption and decryption of the data and also message integrity when you receive a message you want to check has it been modified so the SSL record protocol will do that for you but to encrypt and decrypt we need keys and we so we need the client and server to be aware of each other and to exchange some keys up front before we can encrypt and decrypt so there are three other components of SSL there's a handshake protocol to perform some authentication so before we send data between client and server we send a message between client and server to say we want to send data encrypted and we check that we're communicating with the right entity so we do authentication and we negotiate parameter values for example what algorithm are we going to use to encrypt what hash algorithm are we going to use so that's part of the handshake protocol for the client and server to agree upon those algorithms you may change the encryption algorithm and or the keys during the the transfer of data so you may be using one and you change to another partway through so there's a method for changing the cipher so we'll see in the example there are some changed cipher messages really says let's let's move to the next approach to encrypt and decrypt and maybe the next key and if something goes wrong or we want to tell the other side that some some special thing has happened there's an alert message that can be sent so we talk about the alert protocol so what what happens is that when you use HTTP your browser before it sends the HTTP request it will perform an SSL handshake with this web server agree upon some parameters authenticate each other then eventually it will create the HTTP request and that request will be sent to the SSL record protocol which will then encrypt the request and then send it to the server the server will receive the encrypted request decrypted and then process and send back a response maybe the best way to see that is through an example i've got a capture and i'll show you the existing one but i'll show you what i did first so in my browser i i'll access a website using normal HTTP and i was i actually did this this morning and i captured using tcp dump what i did is captured the messages that my computer sent to the server and what came back and i'll show you that capture in a moment but what i did was first access the website using normal HTTP the reason i access this website is why because it's mine no because it's a very simple one that is that we'll see the content is very simple and because it's mine if it works let's see and we log am i logged in okay it worked and then what i did was i accessed it using HTTPS and i captured the packets in both cases and we'll look at them so this is the the list of captured packets first using HTTP so we will see the what someone in the internet can see if they intercept so sent from my browser here at sit and the servers in tokyo so it was sent across the internet and if someone was in in the path between my browser and server in theory they could intercept all the packets sent and this is what they could see and i'll just make it a bit easier we'll remove the time the source is 192.168.1.7 that's my computer my laptop the browser and we'll see eventually the server is this 106.187.46.22 address that's the web server actually the first thing that happens is DNS which we haven't covered this is because i typed in the domain name what DNS does is before i send the request it says what's the IP address for this corresponding domain name so i send a query and eventually i get a response saying the IP address for that domain name is this 106.187.46.22 address so that's not part of HTTP but commonly used to map domain names to IP addresses so the first one was using HTTP what transport protocol was used for HTTP TCP and what do we do before we send data with TCP before we send data using TCP what do we do between client and server we set up a connection using what the three-way handshake and that's what these three messages are syn we're not looking at the details syn-ac-ac okay this is just setting up the normal TCP connection between client web browser and web server then we send the request for the web page okay so this is the HTTP request message being sent as TCP data to the server there's a tcp-ac and then eventually the server sends back the web page and we'll just look at that one so again someone can intercept this and see all the content because in that HTTP response it says 200 okay it says who's responding and it includes the actual web page that i visited you know the html so this is not confidential communications because someone can intercept and see the content what port number is the server using port 80 we see the port number summarized here my browser is 48829 the server port 80 and in this web page there was actually some references to if we look at it again there's a style sheet in the html there's a reference to a style sheet and i think there may be an image a favorite icon there as well or that the browser will request so we'll see that after the web browser receives the web page then it sends a request for another resource the style sheet in this case and we get the style sheet back and my browser automatically sends a request for the favorites icon to show in my bookmarks or in the in the browser and that sent back okay so there were there's one web page and two objects that are requested and response come back and eventually we close the connection so that's the normal operation html now let's look at the same thing happening but using html s there's a dns query so i did it maybe half a minute later access the same website see i'll get rid of the color coding because it may be confusing here the dns this is the three-way handshake so sets up the connection note the port numbers especially the server port number this is my browser creating a tcp connection to the web server at port 443 so tcp connection is created same ip address but different port number at the server and after the connection we don't send the html request what we do is we use ssl or more precise tls the newer version is called tls the transport layer security and there's some messages exchanged to do the handshake to accrue upon parameters and the messages the first one we see is that the client the web browser sends a hello message to the server the hello message so here we see the content of that hello message it contains some information from my browser to the server what does it contain that maybe we recognize so this is part of the handshake protocol the client saying hello this is the things that i support it actually sends some random numbers we often use random numbers to support the different cryptographic operations importantly it sends a set of ciphers that it supports ciphers the algorithms so to do the encryption it's not just encrypting data but also we have authentication of the server and authentication of the data so there are different combinations of algorithms that we'll use and this is the client my web browser saying i support these 11 different operations 11 different combinations i support using tls uh elliptic curve cryptography with difi helman elliptic curve with the digital signal digital signature algorithm aes for encryption of data that's a symmetric key block cipher aes 128 and the mode of operation i think you may have used cbc in some of your tasks the mode here is gcm and the hash algorithm char 256 so this is saying that the browser supports this combination of algorithms but if the server doesn't want to use that the browser also supports these other 10 so this is just the browser informing the server what capabilities it has we need to use one of them we'll see in the response from the server which one when we encrypt data we may compress it as well so optionally we may compress the data just to save space what compression methods does my browser support which compression algorithms anyone want to guess zip is a good guess but wrong null no compression in this case it doesn't doesn't want to compress okay but you may see zip and other algorithms supported in other cases and the rest the extensions are some other information um some of it's like the server name and and the for some of these algorithms ec elliptic curve they have some parameters associated with them some public parameters and these fields will contain some information that the server can use if it wants to use those algorithms this is the first message to client hello then the server sends back a hello message it's part of the handshake protocol and importantly we see the algorithm combination that it's selected it's selected to use i think it's the first one in this case no it's not the first one it's it's one of the other ones dh is for diffie helman which is a way to exchange secrets rsa is what what type of algorithm rsa is a public key cryptography public key cryptography algorithm we use that for we'll see we'll use that for certificates shortly a s is a symmetric key cryptography algorithm and that will be used to encrypt the data so what we commonly do is to authenticate to check we're communicating with the right person and to exchange keys we may use public key cryptographic algorithms like diffie helman and rsa but then when we want to encrypt the data the fastest way to encrypt data is using symmetric key cryptography and a very common algorithm use today's a s the advanced encryption standard there may be others and with 128 bit key and the mode of operation i don't remember what it stands for is gcm and also we will perform authentication of the data and we use a a hash algorithm there char is the hash algorithm that's used so this is the server saying let's use this set of algorithms and a few parameters are included as well what happens next anyone want to guess so we've agreed upon what algorithms with some negotiation of parameters really the client says what i support the server chooses one of them as long as the server supports it as well now we need to do some authentication and exchanging of keys it's a bit hard to see but the next message is actually combined in a is split across i think one two three four packets it's split across so i'll just look at the fourth which combines it all into one this is from the server so from the server to the browser and part of the handshake protocol the server sends its certificate to the browser and the certificate is used for the browser to confirm that this server that it's communicating with is the correct server it's not a fake server so we'll go into detail about how that works so this message contains the certificate we'll come back to that when we look at what our digital certificates and when the browser gets that it verifies ah this is the correct server we'll see how that works in our lecture and then here's the client and we're almost done i think this is once we've verified the server we exchange a secret okay to encrypt our data we need a secret key shared by both endpoints so we apply some algorithm to to exchange a secret and it uses difi helman is the the algorithm and so this message this key exchange is saying let's use difi helman and these are the parameters we need to use difi helman we didn't study difi helman if you want to know about it you need to sit through the security and cryptography course but this is used to exchange a secret and once we do that we the change cipher means once we've exchanged the secret let's start using a s to encrypt i think the last ones are just some final messages let's see the next message from the client the browser to the server application data what do we see we don't see the content this is encrypted so now we're encrypting the data so the browser is encrypting and then sending it so when we intercept we will not i don't know what's inside this okay so it's encrypted using a s in this case the server can decrypt because they have negotiated a key with the client but we as the interceptor the malicious user cannot see the contents here and i think the subsequent messages encrypted except when they tell each other to change keys or change algorithms so let's filter on ssl just to see all of those messages these are all the messages between browser and server so the first steps after the hello and we exchange we sent a certificate from server to browser that provides some authentication we exchange keys when you see application data that's encrypted data where's the request for the web page this is all the messages here which packet from 28 through to 78 which one contains the first requests for the web page 41 which web page did i request so you may guess that this is the request now assuming you didn't know which what i did on my web browser what was the url that i requested from the web server if you know only this then you open it up and have a look and even if you guess that that's the request you don't know what the content of that request was so you don't know that it was get slash index dot html or get something else so you don't know the exact page i requested you don't know any of the header fields and the response probably one of this one the response that contains the web page again it's all encrypted so you will not know what the actual web page is that i'm viewing we see that then there is another hello and another data can you guess what these other ones are for remember we requested a web page we got the web page then what happened we requested the style sheet got the style sheet and requested the favorites icon and got the favorites icon so i think that's what's happening there the encrypted data of course we don't see that as the malicious user but we we can guess that's what's happening and each time that does that happens there's this the new hello and the setting up of the ciphers then we encrypt the data encrypted alert is just saying this is the end of the communications so the point isn't to understand all the details of SSL just be aware that we say hello to each other which includes negotiating parameters the algorithms to use we exchange some authentication information the certificate we'll look at in more detail and then once we've exchanged keys we can encrypt data no one can see the request or response what can a malicious user learn from this capture which may be useful for the malicious user what can they learn say i did this from my browser and you intercepted using your laptop using wi-fi it was sent by wi-fi you know how to intercept on wi-fi okay you monitor and then capture with tcp dump so you would see this what do you learn about what happened there do you know what web page do you know what website i request i accessed yes you do you know based upon the ip address in the destination here you know i send a message to 106 187 4622 and in fact you know it's to port 443 so you know the ip address of the destination and you can work out that that corresponds to sandylands.info so you do know the web server that i contacted but on that web server you don't know the specific web page that i requested nor do you know what was sent back in response so you know who is communicating but you don't know what they are communicating to hide who is communicating that's about privacy and we'll see that in in the the last topic in this course is well how could we extend this so that someone who intercepts doesn't even know that i'm contacting that particular website that's a different issue ssl doesn't provide that on its own any questions on the the capture i'll put this capture on the website you can have a look in your own time if you like this you'll see the details everyone's okay looking forward to the long weekend i think we all are the other thing what else can we say about ssl ssl has the concept of connections in the same as a tcp connection before we send data we establish a tcp connection and ssl also has a connection associated with a tcp connection so a single client and server may have multiple connections at the same time ssl also has a session and between a single client and server a session maybe have multiple connections associated with it that is what i do when i first contact the server i establish some parameters i i authenticate the server we agree upon some parameters and that's called the ssl session and then in subsequent contacts i may create multiple or new connections to the server and that's associated with the overall session i can reuse some of the parameters that i negotiated at the start just means i don't have to continually negotiate every time i set up a connection i can reuse the information for the session and that that information is stored so the handshake protocol is about establishing the and agree upon agreeing upon the parameters and it's stored at both the client and the server information about who we're communicating with an id the certificate of the server what algorithms we're using some secret values so there may be a master secret like a secret key for the session and then for each connection again there are some other things like at the encryption keys if we're using a message authentication code they also need secrets sequence numbers initialization vectors and other parameters are stored by both client and server sometimes we'll see that the encrypt keys are generated from some master key i think we'll not see an example of that or we're not going to an example of how that works the encryption of the data say this is the http response containing the web page maybe the response is 1000 bytes that's the original application data what ssl does is breaks it into fragments usually smaller fragments the size may may differ compresses them that is usually the size of the fragments is the same but the the exact size of each fragment used may be different in different cases we compress them or optionally compress them each fragment we add a mac and i think we didn't cover message authentication codes but this is used for data integrity it's so when the receiver gets it it can check has the data been modified that's what the mac is used for we encrypt everything say using aes and we append a header the ssl record header to tell the other side what some information about this fragment and we do that for each fragment if this is the http response and we break it say into three fragments each fragment we may compress add the headers and so on first thing regarding performance is that to do this it may take some time encryption takes time so you may find that using htps and ssl in general may be slower from the user's perspective than not using it because normally you just send a request get a response but with ssl we need to create a request compress so the compression algorithm may take some time calculator mac encrypt takes some time and then send each fragment one at a time so it may take time on the computer to process at the encryption stage and decryption stage and also we may send multiple fragments which takes more time so there may be some overhead some some slower performance using ssl compared to not using it in some cases what we send may be larger depending on whether how the compression is being used but if there's no compression you'll see that what we send is actually includes extra headers so it may be larger than what the original application data was so extra overhead we saw an example of the handshake protocol there goes through different phases we establish the capabilities of each other we tell each other what we support the client proposes a set of algorithms the server selects one of them to use what if the server doesn't support the ones proposed then they will not be able to establish a connection so if the the client only wants to use this combination and the server doesn't want to use that because it doesn't believe that combination to be secure then they cannot set up a connection then they perform authentication that is the browser authenticates the server they exchange some keys and optionally the server authenticates the client with HTTPS we usually don't do the server authenticating the client in part of SSL we do it outside in HTTP then they set up the connection and then they exchange encrypted data so step five send encrypted data so these are the four steps of the handshake then we exchange the encrypted data with the record protocol and we saw in the example that there are different algorithms that can be used there's algorithms used for key exchange agree upon keys to use there are algorithms algorithms used for data integrity message authentication codes and it's HMAC using either SHA or MD5 we saw an example that used SHA256 and there are different algorithms used for encryption in our example we saw it used AES so those first hello messages they they chose which algorithm combination to use one form of authentication how does the client know it's talking to the correct server we saw the server sent a certificate to the browser so the next part is to look at well what is a certificate and how is it used by the browser to authenticate the server