Recently, I have to use Linkedin API to crawl companies in their ecosystem. The official API (v3)requires OAuth for authenticating and forces you to request to them before you can use the full version (public and private APIs). Luckily, I found that Linkedin offers Voyager API for searching and listing companies unofficially. It allows you to use your email and password for authenticating instead of OAuth tokens.

However, Linkedin seems to restrict calling to their APIs by checking the IP addresses. According to my observations, calls from IP addresses that never logged in with the given account before will be blocked and required a verification called the challenge exception. The only way to deal with this problem is logging in manually before calling API. However, in a non-UI environment like Linux-based production servers, you don’t have browsers and you’ll need a script to do that.

I have written such a script, you can find at my Github repository below

everping/Linkedin-Authentication-Challenge
When using Linkedin API for the first time in a production server, you may get Challenge Exceptions. That's because you…github.com

Read this article at my company’s blog

As I described in the chapter one, we can control the content of a sub-domain d by controlling the content of domain d1 that d point to through its CNAME record.

Azure, a popular cloud service offer many services that can create such a d1. In this article, I will go details about services of Azure that can be vulnerable and how I exploited in the wild, including: Traffic Manager Profile, Web App, Virtual Machine

Traffic Manager Profile

Traffic Manager profiles use traffic-routing methods to control the distribution of traffic to your cloud services or website endpoints.

My targets: Microsoft, Deloitte, HP

Normally, we can detect that a domain is using Traffic Manager if its CNAME record is xxx.trafficmanager.net like the following case.

The next step is checking whether the CNAME domain is available to register or not by using Azure API or using Azure portal.

If it is available, just create then in endpoint setting, select type External endpoint and enter your controlled IP address as the target. The final step is to create a PoC page in your server to make the PoC works.

Web App Service

Azure App Service enables you to build and host web apps, mobile back ends, and RESTful APIs in the programming language of your choice without managing infrastructure

My targets: Deloitte, US gov

In this case, the original domain points to xxx.azurewebsites.net

Similar to the Traffic Manager Profile, we have to check check the destination domain’s availability and if it’s available, create your own app. Then push whatever you want to it to prove that you can control the domain.

Note: I have reported that bug to the US Cert and they fixed afterwards.

Virtual Machine

Azure Linux Virtual Machines provides on-demand, high-scale, secure, virtualized infrastructure using Red Hat, Ubuntu, or the Linux distribution of your choice

My targets: BBC

Compare to those cases, the destination domain in this case includes the region name, its form is xxx.region_name.cloudapp.azure.com

Steps to exploit

1. Create a Virtual Machine, Ubuntu server for example. You must select the correct region with the region in that CNAME. In this case, it is North Europe

2. In Overview setting, change DNS name to discussions-stage.northeurope.cloudapp.azure.com

3. Install a webserver (Apache, Nginx) in the VM just created and create a virtual host for it to serve requests to discussions.stage.api.bbc.com

Fun facts

• Roughly 40 domains of Microsoft affected by this issue. Their security team responded quite slowly and did not reward for the finding since it is out of scope. However, they gave me a sincere thanks and acknowledged me in MS Hall of Fame (2 times for 2 reports)

• BBC gave me a T-shirt and acknowledged me their Hall of Fame

• About 140 domains of Deloitte, one of the world’s largest auditing companies, are vulnerable. Reporting bugs to them is probably one of the worst experiences of my career. When I found issues in their domains, I tried to find their security contact but got nothing; I also sent emails to the addresses I saw on their official websites but got no responses after 1 week. Finally, I used Linkedin and texted to some people that I think they work there, one of them replied me that she forwarded my message to the security team. Sadly, she just quit her job there for a short time. The security team then contacted me and asked me for details. What happened after that was that they said they received the information and ended the conversation. I’m also not sure if those problems have been fixed. Honestly, I have no intention of reporting the vulnerability to this company anymore.

Read this article at my company’s blog

Subdomain takeover is a high severity vulnerability that can be exploited to take control of a domain and pointing it to an address managed by attackers. Attacks on this vulnerability are often used for the purpose of creating phishing sites, spreading malwares. However, subdomain takeover is not a new vulnerability, it may be published from the year of 2014.

On the last weekend of October, I spent some time coding exploits to find major websites that could be affected by the vulnerability. The results were very unexpected, I found more than 200 domains affected by the vulnerability just in 2 days. These domains belongs to big technology, finance companies and major newspapers. I suppose that I should share my discoveries with subdomain takeover, so this series will show my perspective, how do I find out vulnerable websites and how to exploit them, on a case by case basis.

Domains and IP addresses

To begin with, let’s talk about a typical example. You own a domain example.com and a server with the IP address 1.2.3.4. Now you would like to point your domain to this IP address?

Normally, your DNS providers offer several ways to do this, including:

• Using A or AAAA records

• Using CNAME records

• Using extra records like ALIAS or URL records

We will look into the details in each of these ways

Using A or AAAA records

This is the most common way, almost everyone who works with domain names has ever used this method. We will have to enter a host and a value as the domain name and the IP respectively.

Notes:

• @ used to point a root domain (example.com) to the IP address

• xxx used to point a sub-domain (xxx.example.com) to the IP address

• A records are for IPv4, while AAAA records are for IPv6

Using CNAME records

A/AAAA records is a direct solution for the domain name resolution. However, in some cases this method will cause annoyance, for example:

• You own 100 subdomains (x1.example.com , x2.example.com ... x100.example.com) and all of them are pointed to the IP 1.2.3.4. One day, you changed the host and the IP is changed to 5.6.7.8. Would you update the A record for 100 sub-domains?

• You are using a 3rd party service to create a landing page for your advertising campaign. This partner created a site with domain yourcompany.ads.com. However, you wouldn't like to use this domain, simply because it is unfamiliar to your customers. How to point your own domain landing.example.com to yourcompany.ads.com?

You can use CNAME records for these cases. CNAME is the most well known way to “symlink” one DNS record to another. It works by answering queries asking for the Source with a simple referral (by domain name) to the Target, which may be anywhere else on the internet.

For example 1, we will need to point subdomain x100.example.com to the destination IP by using the A record, then point 99 other sub-domains to x100.example.com by using the CNAME record. Later, if the destination IP is changed, we will just need to update the A record of x100.example.com.

For example 2, we will need to point the CNAME of landing.example.com to yourcompany.ads.com.

The biggest problem with CNAME is that it cannot be used for a root domain, but only sub-domains.

Using ALIAS and URL Redirect Records

These are records not in the DNS RFC, so they are only supported by certain DNS providers. ALIAS is a pseudo-record that works like a CNAME but can be used for both the root domain and sub-domains. The URL Redirect record is used to redirect a domain to another URL/domain name.

Subdomain takeover attack

The goal of this attack is to point a victim’s domain to an attacker’s address. This is closely related to the domain resolutions I have described above. In the case of using A/AAAA records for the resolution, it’s not worth mentioning but the remaining cases have weaknesses.

Let’s look at a scenario as follows:

• You own x.example.com

• x.example.com points to another.domain.com by using a CNAME record

In order to control the content of http://x.example.com, we have to control the content of http://another.domain.com. This is possibile, if:

• another.domain.com is an expired domain -> Buy this domain

• domain.com belongs to an Internet service and it allows to create a sub-domain like another.domain.com if that name is available. You can find out many serives having that feature such as Github, Heroku, Amazon S3, Shopify, etc.

I did not think this attack was effective until I proceeded to find the subdomains of many big firms and checked the feasibility of the attack. As I said at the beginning, the results are verysurprising. One of them are microsoft.com, but subdomain takeover vulnerability is considered as out-of-scope of their bug bounty programs so I was only acknowledged in their Hall of Fame.

The method I used was:

• Find all subdomains from a domain by using SubStack

• Check the exploitable signature of sub-domains found. I have used signs published here as well as my own techniques.

In the next article, I will present more specific cases that I have successfully exploited.

If you want to get top visited websites, Alexa is a reliable source. But, sadly, they only free the first 50 websites, and if you want to get more, you have to pay a fee.

One of the ways to obtain that list is to use AWS service with price $0.0025 per URL. Everything seems easy when you are willing to pay, however, their sample code is only available ruby, php, java that I do not like them. I have rewritten a small script in Python to do this, you can check it bellow.

Anw, the process of creating AWS authorization headers is extremely complex.

My source code

If you are a mobile application developer, you may be interested in exposing sensitive information from your application because of decompilation a mobile app such as Android app is not too difficult.

A friend of mine recently developed an Android application using Unity framework, it can hide code by downloading the required modules from a trusted-server at the runtime.

I really doubt this method, so I try to reverse this app to obtain the hidden code. And in this article, I will describe my work process.

You can download the APK file here. Notice this file is not the original version, it was modified to fit the article.

Analysis

Running

When running the application on an Android Emulator, you will see results like bellow.

Static Testing

In Unity Framework, the main code is written by C# language and compiled to a dll file. It’s compressed in the the binary file. After extract the apk file, we can see it at: /assets/bin/Data/Managed/Assembly-CSharp.dll

We easily decompile a dll written in C# by using decompilers such as dnspy, ilspy or dotpeek…

At line 39, the app loads Component ExtendModuleActivity

At line 40 and 41, displaying the content of the Component above to screen. It is “Find me if you can!” string that we have seen when runing the app.

So, where is ExtendModuleActivity? I haven’t seen it in the decompiled code. I assume that the decompiler is not effective and it does not show the source code completely

Dynamic Testing

I suspect the app downloaded required modules via HTTP, so I do some configs to force this app goes through a HTTP Proxy (such as ZAP, BurpSuite …) to know what it actually does. Note that you make sure your proxy can sniff the HTTPS Request by trusting Proxy’s Certificate in Android Client.

Then open the app and observe at the proxy

This app downloaded two resource from a remote server:

• https://raw.githubusercontent.com/everping/remote-asset-bundle-unity/master/assets/ping

• https://raw.githubusercontent.com/everping/remote-asset-bundle-unity/master/assets/bundle

The first resource is a text file that contains the content that appears on the screen, and bundle seems to contain ExtendModuleActivity that we are looking for.

In Unity Framework:

An AssetBundle is a collection of assets and/or scenes from a project saved in a compact file with the purpose of being loaded separately to the built executable application.

AssetBundles can contain scripts as TextAssets but as such they will not be actual executable code.

Extract the Bundle

I found a pretty good tool to extract bundles called Unity Assets Bundle Extractor

Load our bundle to UABE and view its information

Then Export Raw to obtain the bytecode. Using an editor / hex editor, we can realize that it is PE File (beginning with MZ), but was inserted into the previous another section. We just remove this section to restore PE header file.

The rest is decompiling the new file, and this is what we are looking for :)

Conclusion

As you can see, securing applications is not an easy task. Using Remote Asset Bundle is not a perfect way to hide your source code in Unity Framework, and in addition it is appropriate only when your application requires an internet connection. This article does not go into how to prevent attacks, I just hope it can be to raise awareness about some risks in your application. Good luck!

P/s: Maybe I will implement this technique into a CTF challenge in the future.

Gần đây tôi có thấy nhiều thông tin về lỗ hổng này, được đánh giá là Serious, cho phép leo thang đặc quyền, ảnh hưởng đến nhiều distro Linux… Tôi cũng không hiểu sao một lỗ hổng sau khi được công bố thì có logo, website riêng, Twitter, Facebook Page thậm chí là có cả một cái shop bán đồ lưu niệm :| Vì tò mò nên cũng muốn tìm hiểu cơ chế hoạt động của vuln này, dù tôi không phải người chuyên research OS Kernel.

Dirty COW được gán mã lỗi CVE-2016-5195, là một cái bug Linux Kernel Race condition cho phép leo thang đặc quyền thông qua Local Exploit (nghĩa là kẻ tấn công phải vào được server nạn nhân trước với quyền Normal rồi dùng lỗi này để nâng lên quyền root). Dirty COW ảnh hưởng đến nhiều phiên bản Kernel(2.6.22–3.9) và hầu hết các distro Linux thông dụng, nhưng cách khai thác thì rất đơn giản và hiệu quả.

Người phát hiện ra lỗi này, Phil Oester, công bố sau khi một server anh này quản lý bị tấn công bằng chính Dirty COW. Có nghĩa là mã khai thác hiện có đã bị dùng để tấn công thực tế từ rất lâu rồi. Cha đẻ Linux, Linus Torvalds cũng đề cập trong bản vá lỗi rằng anh đã mường tượng lỗi này có thể xảy ra, và đã đưa ra bản vá vào năm 2005 nhưng nó đã không thực sự phát huy tác dụng.

Trong bài viết này, tôi sẽ cố gắng giải thích chi tiết cách lỗi này hoạt động. Và nếu có gì sai sót, hy vọng ai đó có thể góp ý thêm.

Chi tiết lỗi

Một cách phân tích bug hiệu quả là dựa vào mã khai thác đã có. Dưới đây là đoạn mã được cung cấp từ repository github “chính thức” của Dirty COW.

dirtycow/dirtycow.github.io
dirtycow.github.io - Dirty COWgithub.com

Mã khai thác này cho phép sửa nội dung một file đã được set permision Read Only, hoạt động được trên hầu hết các distro Linux trừ Red Hat Enterprise Linux 5 và 6 (lý do sẽ giải thích ở dưới). Cách dùng thì có thể thấy dễ hiểu thế này:

$ sudo -s

# echo this is not a test > foo

# chmod 0404 foo

$ ls -lah 
foo-r — — -r — 1 root root 19 Oct 20 15:23 foo

$ cat foo
this is not a test

$ ./dirtyc0w foo m00000000000000000

$ cat foo
m00000000000000000

Theo luồng xử lý của chương trình, chúng ta có thể chia nhỏ các công việc mà nó thực hiện như sau.

1. Load file và map vào Virtual Address Space

Tại dòng 87, chương trình mở file input và đọc với chế độ Read Only. Tiếp đến lấy thông tin file ghi vào biến con trỏ st và lưu lại tên file vào biến name. Mọi thứ khá rõ ràng.

87: f=open(argv[1],O_RDONLY); 
88: fstat(f,&st); 
89: name=argv[1];

Ở dòng 101, nội dung file được map vào Virtual Address Space bằng hàm mmap()

101: map=mmap(NULL,st.st_size,PROT_READ,MAP_PRIVATE,f,0);

mmap() không copy nội dung file được vào RAM, mà ánh xạ nội dung này vào vùng nhớ ảo của tiến trình đang chạy.

Hãy xem qua đặc tả hàm:

void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);

Tham số addr trong trường hợp này là NULL, nghĩa là kernel tự quyết định địa chỉ lưu trữ, độ dài vùng nhớ length bằng độ lớn của file st.st_size, chế độ truy cập prot vẫn được để là Read Only PROT_READ vì thế vùng mapping này chỉ có thể được đọc, fd và offset tương ứng với file input và vị trí bắt đầu load file. Và tham sốquan trọng nhất ở đây, flags được gán bằng MAP_PRIVATE.

Theo như tài liệu của linux:

MAP_PRIVATE: Create a private copy-on-write mapping

Copy-on-write là một khái niệm quan trọng của hệ điều hành, tư tưởng của nó là nếu một tiến trình đọc một tài nguyên dạng copy-on-write thì sẽ vẫn như đọc tài nguyên thường, nhưng nếu thực hiện thao tác ghi/sửa thì hệ điều hành sẽ tạo một bản sao của tài nguyên đó và cập nhật các nội dung mới vào đây, bản gốc không bị thay đổi.

Với cờ MAP_PRIVATE, bản mapping được xử lý riêng với tiến trình sở hữu nó. Các thay đổi về nội dung trên mapping không ảnh hưởng đến bản gốc và cũng không chịu sự tác động của bất kỳ tiến trình nào khác. Cụ thể hơn, nếu chúng ta sửa nội dung file input sau khi đã map vào Virtual Address Space thì file gốc không bị thay đổi.

Cụm Copy-on-write cũng chính là dạng đầy đủ của từ COW trong cái tên Dirty COW

2. Race Condition

Như đã nói ở phần đầu, Dirty COW là một lỗi Race Condition, và lỗi này được tạo ra bởi 2 dòng lệnh sau:

106: pthread_create(&pth1,NULL,madviseThread,argv[1]); 
107: pthread_create(&pth2,NULL,procselfmemThread,argv[2]);

Về cơ bản thì Race Condition xảy ra khi mà có nhiều hơn một luồng thực thi cùng đọc/ghi vào tài nguyên dùng chung dẫn đến xung đột và những tình huống không đoán được trước. Trong trường hợp của Dirty COW, các luồng thực thi này là 2 thread madviseThread và procselfmemThread, còn tài nguyên dùng chung là bản mapping của file input. Ta sẽ đi cụ thể vào từng thread.

1. madviseThread()

Chú ý vào dòng 45, đây là lệnh quan trọng nhất của thread này. Còn vòng lặp for chỉ giúp cho Race được diễn ra.

45: c+=madvise(map,100,MADV_DONTNEED);

madvise là một system call, nó đưa ra chỉ thị cho kernel biết phải làm gì với không gian nhớ bắt đầu từ addr và có độ dài length

int madvise(void *addr, size_t length, int advice);

Ở đây, chỉ thị là MADV_DONTNEED, nó yêu cầu kernel không sử dụng không gian nhớ này nữa và có thể giải phóng tài nguyên liên kết đến file input. Lúc này vùng nhớ trên trở thành dirty, đây là từ đầu tiên trong tên Dirty COW. Với vùng nhớ dirty, lại có thêm chỉ thị MADV_DONTNEED (do thực hiện vòng lặp), dữ liệu ghi vào sẽ bị “ thrown away”, còn dữ liệu đọc ra vẫn sẽ được lấy từ file gốc.

Tóm lại, mục đích thread này là ngăn cản việc sử dụng vùng mapping.

2. procselfmemThread()

61:     int f=open("/proc/self/mem",O_RDWR); 
62:     int i,c=0; 
63:     for(i=0;i<100000000;i++) {
64: /*
65: You have to reset the file pointer to the memory position.
66: */ 
67:         lseek(f,(uintptr_t) map,SEEK_SET);      
68:         c+=write(f,str,strlen(str)); 
69: }

Chúng ta đã biết là không thể ghi vào file input được, do nó được set permission Read Only. Vì thế, người viết mã khai thác này thực hiện một trick là ghi vào vùng không gian nhớ đã được map, thay vì file gốc. Cách thực hiện là thông qua /proc/self/mem.

Trong các hệ điều hành *nix thì Everything is a file và memory cũng không ngoại lệ, vùng nhớ của mỗi tiến trình có thể truy cập thông qua file /proc/<pid>/mem. Ở đây, POC process truy cập chính vùng nhớ của mình nên pid = self.

Và đoạn mã phía trên thực hiện việc ghi vào vùng mapping một cách liên tục (bằng vòng lặp) dữ liệu mà user truyền vào.

Phương pháp ghi vào mem này hoạt động tốt trên phần lớn distro Linux trừ Red Hat Enterprise Linux 5 và 6, vì mấy distro này không cho phép ghi vào /proc/self/mem. Đấy là lý do tại sao mã khai thác này không hoạt động được trên những distro đấy. Ở những trường hợp này thì có một cách khác thay thế là dùng ptrace() system call.

Đến đây thì chúng ta có thể hình dung ra được là có 1 thread liên tục free vùng mapping, còn thread còn lại thì liên tục ghi vào đấy.

Nếu mọi chuyện tốt đẹp thì sẽ như thế này:

Tuy nhiên thực tế lại xảy ra không như mong đợi (cũng là vì Race):

Chú ý một chút, chúng ta thấy là nếu 2 thread trên hoạt động độc lập hoặc có thứ tự thì nó vẫn có thể coi là bình thường hoặc chỉ sai một chút về logic. Tuy nhiên cái vấn đề sai ở đây là procselfmemThread() đang cố tình ghi vào một vùng mapping được định nghĩa là Read Only (dòng 101) cộng thêm việc vùng này đã bị clear bởi madvise() trước đó. Điều này dẫn đến 1 cái fault mà Linus Torvalds đã nhận ra từ 11 năm trước, nó cho phép break COW để ghi trực tiếp nội dung vào file gốc. Anh này cũng đã fix lỗi này tại thời điểm ấy, tuy nhiên không thật sự thành công.

Vá lỗi

Trên Linux repo, chúng ta có thể thấy cách Linus Torvalds vá lỗi này. Một cờ mới là FOLL_COW được đưa vào để đảm bảo quá trình COW đã hoàn tất trước khi 1 thread khác xen vào.

+/*
+ * FOLL_FORCE can write to even unwritable pte’s, but only
+ * after we’ve gone through a COW cycle and they are dirty.
+ */
+static inline bool can_follow_write_pte(pte_t pte, unsigned int flags)
+{
+    return pte_write(pte) ||
+    ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte));
+}
+

Kết

Dirty Cow là một lỗi nghiêm trọng, dù nó chỉ thuộc loại Local Exploit nhưng thời gian tồn tại trước khi công bố cũng đủ lâu để ai đó làm gì biến mọi thứ trở nên nguy hiểm hơn. Nhiều thiết bị android cũng đã được xác nhận có ảnh hưởng. Vì thế, hãy cập nhật hệ điều hành của các bạn sớm nhất có thể và đặc biệt là với các Honey pot hay Vuln Server của các cuộc thi CTF. Thông tin thêm có thể tìm thấy ở trang chủ Dirty Cow.

Tài liệu tham khảo

[1] https://dirtycow.ninja/

[2] https://github.com/dirtycow/dirtycow.github.io

[3] http://man7.org/linux/man-pages/man2/mmap.2.html

[4] http://man7.org/linux/man-pages/man2/madvise.2.html

[5] https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/mm/madvise.c#L452

[6] https://en.wikipedia.org/wiki/Copy-on-write

[7] https://en.wikipedia.org/wiki/Dirty_bit

[8] https://sandstorm.io/news/2016-10-25-cve-2016-5195-dirtycow-mitigated

[9] https://github.com/torvalds/linux/commit/4ceb5db9757aaeadcf8fbbf97d76bd42aa4df0d6

[10] http://www.v3.co.uk/v3-uk/news/2474845/linux-users-urged-to-protect-against-dirty-cow-security-flaw

[11] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619

[12] https://www.youtube.com/watch?v=kEsshExn7aE

We’ve heard a lot about HTTPS, and we use it every day. If you access a website from your browser and you see a little green padlock and the letters “https” in your address bar then congratulations, you are accessing this safely via HTTPS.

HTTPS is a combination of HTTP Protocol and an SSL/TLS encryption layer. When the server uses HTTPS, unless they make any mistake during setup, a 3rd party will not intercept and decrypt the data sent between client and server.

In this post, I will explain to you in detail how HTTPS works and the importance of the SSL handshake. I also referred to Rob Heaton’s blog, this is really an informative article to read.

I assume you know about HTTP Protocol before reading this post. If not, you should read RFC2616 before.

About SSL / TLS, it is a cryptographic protocol that provides communications security over a computer network. SSL standing for Secure Socket Layer was invented by Netscape. According to Wikipedia, version 1.0 was never publicly released; version 2.0 released in February 1995 “contained a number of security flaws which ultimately led to the design of SSL version 3.0”. SSL version 3.0 of 1996 represented a complete redesign of the protocol.

Soon after, the Internet Engineering Task Force (IETF) began to develop a standard protocol that provided the same functionality. They used SSL 3.0 as the basis for that work, which became the TLS (Transport Layer Security) protocol.

The SSL/TLS layer has 2 main purposes:

• To verify that you are talking directly to the server that you think you are talking to

• To ensure that only the server can read what you send it and only you can read what it sends back

How an SSL connection is established?

After establishing TCP Handshake and before sending/receiving a HTTP Request, HTTPS also sets up a “negotiation” between the client and server via SSL/TLS protocol called SSL/TLS Handshake, which differentiates it from HTTP. The goals here are:

• To ensure that client is talking to the right server

• For the parties to have an agreed-upon “cipher suite” including which encryption algorithm they will use to exchange data

• For the parties to have agreed-upon keys necessary for this algorithm

To make it clearer, I use openssl to connect to google.com

openssl s_client -tls1_2 -connect google.com:443

And use Wireshark to capture and filter it

ssl.handshake

The screenshot above shows all frames during the handshake, it can be divided into 3 main phases

1. Hello

This phase includes frames no. 142 and no. 144 .

First of all, Client send Server a message called Client Hello which contains following information:

• SSL/TLS version that Client wants to use in the handshake

• Some random bytes generated by Client that, afterwards, will be used to generate a master key for encryption.

• A list of encryption algorithms called cipher_suites that Client supports.

• A list of compression algorithms that Client supports.

• And a list of Extensions. These extensions are not required, but if the server understands, they will be used.

The server responds with a Server Hello, which contains similar information required by the client, including:

• Some random bytes generated by the server that, afterwards, will be used to generate a master key for encryption

• The cipher suite selected by the server (from the previous list sent by the client) that will be used for authentication, encryption and verification of the messages

• The compression algorithm selected by the server (again from the previous list sent by the client) that will be used for compressing each message

• If a extension is accepted by the server, it will notify Client in the Extension tag

2. Certificate Exchange

When the client and server have finished greeting, the server must prove to the client that it is the one Client wants to talk to. This can be done using SSL Certificate.

An SSL certificate contains various pieces of data, including the name of the owner, the property (eg. domain) it is attached to, the certificate’s public key, the digital signature and the certificate’s expiry date.

The client can implicitly trusts the certificate, or check if it is verified and trusted by one of several Certificate Authorities (CAs). Please be noted that for some particular applications, the server, in turn, can require a certificate to verify the client’s identity.

3. Key Exchange

This is the most exciting phase of the handshake. The purpose of this phase is for both parties to agree on a private key. This key is encrypted by asymmetric algorithm (e.g RSA, Diffie Hellman) with the server’s public/private keys. Then it will be used in another symmetric algorithm to encrypt data sent between the client and the server. Both symmetric and asymmetric algorithms have already been agreed on during the Hello phase.

In detail:

• Client generates some random bytes called PreMaster Secret, encrypts this using asymmetric algorithm with public keys (found on its SSL Certificate) and sends to the server.

• Server decrypts ciphertext by private keys and gets PreMaster Secret

• Both client and server use PreMaster Secret to generate Master Secret and Session Key. Master Secret is a shared key to encrypt data sent between the client and server. This process is called Client Key Exchange.

In case Client does not have enough data to generate PreMaster, Server must take the additional step called Server Key Exchange before sending the missing data to the client.

When two parties have a agreed on a shared key, Client notifies Server that it’s time to encrypt communication by sending a Change Cipher Spec Message. This is the final message can be read as plain text before encryption.

Finally Client and Server each sends Encrypted Handshake Message to test. Handshake process ends.

Cipher Suites

In Hello Phase, we can see that Client and Server agree on a Cipher Suite. So, what is this?

Cipher Suite is a list of algorithms which Client and Server use during the handshake and data transmission. There are 4 algorithms:

• Key Exchange algorithm: The asymmetric encryption algorithm to encrypt and decrypt shared key. E.g RSA, DH, ECDH, ECDHE

• Authentication algorithm: The encryption algorithm to authenticate server or client. E.g RSA, DSA, ECDSA

• Bulk cipher algorithm: The symmetric encryption algorithm to encrypt and decrypt data sent between Client and Server. E.g AES, 3DES, CAMELLIA

• Message Authentication Code algorithm: The hash algorithm. E.g SHA, MD5.

Example: We have Cipher Suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Where:

• TLS is the protocol

• ECDHE is Key Exchange algorithm

• ECDSA is Authentication algorithm

• AES_128_GCM is Bulk cipher algorithm

• SHA256 is Message Authentication Code algorithm