SAP-C02 Amazon AWS Certified Solutions Architect Professional – New Domain 5 – Continuous Improvement for Existing Solutions Part 11

54. Origin Access Identity

Hey everyone and welcome back. In today’s video, we will be discussing about the origin access identity. Now generally, whenever you have a Cloud Front distribution, so let’s assume that this is the Cloud Front distribution here and here you have the origin. So this origin has certain contents, it can be certain files, images, songs, videos, etc. Now, once you have designed the Cloud CloudFront distribution, what happens is that user will visit the Cloud Front distribution and from here the contents will be served. Along with that, Cloud Front will also ensure that all the contents that can be cached is pushed towards the edge location so that the load over the server does not increase.

Now this is the cachability part. Second important part is that you can have various security mechanisms in the Cloud Front level. So you can have a web application firewall at the Cloud Front level. So it blocks all the malicious web application attacks, et cetera. Now what an attacker can do over here is that instead of visiting the Cloud Front because let’s say you have a valve, now AWS can integrate with Cloud Front. It cannot integrate with the server or cannot integrate it directly with the S three bucket. So now, attacker first tries to send certain malicious packets.

Now he realizes that something is blocking that malicious packet. There might be some kind of a firewall. So now what he does is instead of going to the root of Cloud Front, he directly accesses the server or he directly accesses the S three bucket. So in this way, he can completely bypass all the mechanisms which is there within the Cloud Front distribution.

So with the help of origin access identity, what we do is we tell the S three bucket to only accept the connections which are coming from the Cloud Front distribution. It should not accept any direct connections which are being established. So let’s do one thing. Let’s look into how exactly we can achieve this. Now. I went by s three console. So this is the S three bucket where there are two files. And along with that, we also have the Cloud Front distributions which are present over here.

Now, if I directly open up this specific file from SRE bucket, let’s try it out. So if I do a curl on index HTML so this time we are directly loading it from the SA bucket. You see, it basically gets us the content of welcome to the website. Now this is similar to what we were discussing where attacker is directly loading the page over here. Even though there is a Cloud Friend distribution, he’s bypassing that.

So in order for us to ensure that the origin only accepts the connection from Cloud Friend, we need to have the origin access identity to be enabled. So let’s go back to the Cloud Front distribution. I’ll open up the distribution here. Let’s click on Origin and origin groups. So this is our origin over here, let’s click on Edit here. Now here, this is the origin domain. Now, if you see, there is an option of Restrict Bucket Access.

Now, when you do a Restrict Bucket Access, let’s actually open this Help menu. It basically says that if you want to require that a user always access your S Three content using the Cloud front URL and not the S Three URL, click yes. And this is very important. So let’s click on Restrict the Bucket Access and within the Origin Access identity over here, you can go ahead and create a new identity. Now, there also one more option. Call as grant read permission on the bucket. So you need to select yes, update the bucket policy. We’ll look into what exactly this does. I’ll go ahead and I’ll edit this. All right, so now let’s go back to the CloudFront distribution. So currently the status is in progress. So let’s quickly wait for a moment for the progress to be deployed. So it has been close to around five minutes, and our CloudFront distribution status is now deployed.

So now, if you go to the S Three bucket, let me go to the S Three console. So this is our bucket currently. Now, if you look into the Bucket Policy, let’s go to the Permission. And if you look into the Bucket Policy, CloudFront has added a new Bucket policy. So what this Bucket policy does is that it basically tells that there is this principle. So this is the CloudFront distribution, and this CloudFront distribution will be able to perform a Get object operation on all the files within this specific bucket.

So this is the policy that it has added. Now, since this bucket is currently public from the CLI, even if you directly make a request to the SV bucket, you see, it will still load. So what we need to do is we need to change the permission and we have to make this bucket as private. So from the public access, I’ll remove the Read bucket permission and I’ll click on save. Once done, we’ll do one more thing.

Let’s go to the Public access settings. I’ll click on Edit and we’ll just restore things to the default settings, which was there when a bucket is created. All right? So once you have done this, you can go ahead and click on Save. I’ll click on confirm. Now, once you have done that, basically this permission will block the public ACLs over the bucket and its associated objects.

So now, within the CLI, if you try to load the index HTML from the S Three bucket directly, you see it is basically giving you the access denied. Now, the only way in which external person will be able to access the contents in the S Three bucket would be through the Cloud front distribution. So let’s try it out. I’ll copy the distribution domain name. Let’s do a curl.

And now you see, you are able to see the welcome to the website page. So I hope with this demo you understood on what the origin access identity is all about. So now what we have done is we restricted the SD bucket in such a way that only CloudFront distribution will be able to access it and no external user will be able to directly connect to the data within the bucket. So this is the highlevel overview about the origin access identity. I hope this video has been informative for you and I look forward to seeing you in the next video.

55. Server Name Indication (SNI) in TLS Protocol

Hey everyone and welcome back. Now in today’s lecture we are going to speak about the server name indication which is also referred as SNI. Now, SNI is quite important topic as far as the TLS is concerned and even in exams you might find a question or two related to the SNI topic. So let’s go ahead and understand more about SNI. Now, going back earlier, specifically when it comes to the Https based website, let’s take a scenario where you have a client, you can consider this as a web browser and you have a server. Now, in the TLS handshake, the first thing that really happens is the client sends a client hello. Now whenever a client sends a request, if it is an Https based website as we have already looked into, the server will reply back along with the certificate which is mostly signed by the certificate authority. Now this certificate the client browser will verify against various CAS which are root CAS which are installed in the browser and then the other steps follow.

So this is a very simple scenario and we have a happy, happy ending. But things after virtualization came, things became much more challenging. Now, one of the major challenges is that what would happen if there are multiple websites running in the same server and each of the website has its own certificate. So if a client is requesting or it is sending a client hello to the server, the server should send which certificate should it send the certificate of website one? Should it send the certificate of website two? Or certain times when the shared hosting related feature comes, there are like ten to 20 websites in a single server and thus the older approach does not really work.

And this is the reason why the SNI extension came into picture in the TLS protocol. So what happens in the TLS protocol with the SNI extension is that whenever client sends the request to the server, it will specify the server name. So it will specify if it wants to connect to server one or if it wants to connect to the server two. Now, once the web server knows that it wants to connect to the server one, it will go ahead and retrieve the certificate and send it back to the client. And same goes with the server two. If the client specify that it wants to connect to the server two, then the server two certificate will be fetched and sent it back to the browser. So let’s do one thing. Let’s go ahead and look into how exactly this would work with our favorite wireshark. So I’ll start my wire shock and we’ll be using the WiFi interface because I’m connected to the WiFi and I’ll start the packet capture. Now I’ll just go to some random website which has Https.

So Https got loaded and you will see that let me go a bit down. So this was the DNS query and if you go a bit down, there are some client hello packets. So client hello is one of the first steps in initializing the TLS connection. So within that client hello packet, let’s go to the handshake protocol. So there are various extensions, you will see there are various extensions which are part of the protocol. Let me just maximize it so that it will become much more clear.

So this is the client hello packet and within the client hello packet, there is an extension of server underscore name. So this server underscore name is basically the SNI extension. Now you see server name indication extension. Now, within the server name indication extension, you will see there is the server name which is Youtube.com. And this is how when the client sends a request. So this is my local IP and this is the IP of the YouTube server. So when my browser made the request to this IP address within the client hello packet, it has specifically said that I want to access the Youtube. com and then the server will send back the Youtube. com certificate back to my browser which my browser can verify with a certificate authority. So this is the basic about the SNI extension. So let’s go back to the topic and let’s look into some of the benefits that the SNI brings. Now, one important thing to remember that the SNI extension is supported in the modern browser.

So if you go back, there are a lot of legacy client who do not support SNI extension and thus they will not be able to support if there are multiple websites with the SSL certificate sharing a single IP. And thus what those legacy clients want is they want that there should be only one website with the SSL certificate per IP. Okay? So you cannot have one single IP having multiple SSL certificates. So that is not supported by the legacy client. So let’s look into the benefits. So, prior to SNI, a website needed to have a dedicated IP address in order to have an SSL certificate to be installed. This is very important. If you did not have a dedicated IP, you could not really have a SSL certificate.

The browsers will simply not agree to work with that. So however, with the SNI we are finally able to host multiple websites which can share a single IP address and all of these websites can have their own SSL certificate. Now, one important thing to remember is that SNI extension needs to be supported from the browser as well because it is the browser which will be sending the client hello with the SNI extension. So last, which is a very important point, which is some of the legacy client which includes Internet Explorer on Windows XP do not support server name indication and thus your website may break if you are using the different approach of SNI.

So this is the basic about SNI. Let me actually show you one more important thing. So when you go ahead and create a CloudFront distribution which is a content delivery network, let me just go ahead and create a sample distribution. And if you go a bit down in the SSL certificate, let’s click on the custom SSL certificate. And now if you go a bit down, you see there are two options over here. The first option says only clients that supports the Snip based indication.

So this is the first option and for this you don’t really have to pay anything when there’s also a second option which basically assigns your dedicated IP address. So you see cloud front allocates a dedicated IP address at each CloudFront edge location to serve your content over Https. So this specific option is more of to support legacy clients. So if you have a website and you have a significant amount of legacy client who are visiting your website, then if you choose a SNI then all those clients will break. So you need to have a dedicated IP address to make them work. So this is it about the server name indication. I hope this has been informative for you.

• Category: Uncategorized