Enc-DNS-HTTP: Utilising DNS Infrastructure to Secure Web...

Research ArticleEnc-DNS-HTTP Utilising DNS Infrastructure to SecureWeb Browsing

Mohammed Abdulridha Hussain12 Hai Jin1 Zaid Alaa Hussien13

Zaid Ameen Abduljabbar12 Salah H Abbdal1 and Ayad Ibrahim2

1Cluster and Grid Computing Lab Services Computing Technology and System LabSchool of Computer Science and Technology Huazhong University of Science and Technology Wuhan 430074 China2University of Basrah Basrah Iraq3Southern Technical University Basrah Iraq

Correspondence should be addressed to Hai Jin hjinhusteducn

Received 6 August 2016 Revised 31 October 2016 Accepted 15 November 2016 Published 3 April 2017

Academic Editor Pascal Lorenz

Copyright copy 2017 Mohammed Abdulridha Hussain et al This is an open access article distributed under the Creative CommonsAttribution License which permits unrestricted use distribution and reproduction in any medium provided the original work isproperly cited

Online information security is a major concern for both users and companies since data transferred via the Internet is becomingincreasingly sensitive The World Wide Web uses Hypertext Transfer Protocol (HTTP) to transfer information and Secure SocketsLayer (SSL) to secure the connection between clients and servers However Hypertext Transfer Protocol Secure (HTTPS) isvulnerable to attacks that threaten the privacy of information sent between clients and servers In this paper we propose Enc-DNS-HTTP for securing client requests protecting server responses and withstanding HTTPS attacks Enc-DNS-HTTP is basedon the distribution of a web server public key which is transferred via a secure communication between client and aDomain NameSystem (DNS) server This key is used to encrypt client-server communication The scheme is implemented in the C programminglanguage and tested on a Linux platform In comparisonwithApacheHTTPS this scheme is shown to havemore effective resistanceto attacks and improved performance since it does not involve a high number of time-consuming operations

1 Introduction

Digital information and electronic services are delivered tousers through the Internet Information and services are oftensensitive particularly in applications such as online bankingwhich requires secure transactions [1] Services are providedthrough a web server and the user contacts the server byusing an Internet browser such as Internet Explorer (IE) orGoogle Chrome The client and server communicate usingHypertext Transfer Protocol (HTTP)

Modern web security relies on a combination of SecureSockets LayerTransport Layer Security (SSLTLS)withHTTPand this is known as Hypertext Transfer Protocol Secure(HTTPS) However almost all browsers and servers applySSLTLS to secure information transactions [2]

SSL uses server certificates to publish the public keys ofserver each of these certificates is signed by a trusted third

party known as the Certificate Authority (CA) SSL protocolconsists of two phases the handshake phase and the datatransfer phase and the details of these are discussed furtherin Section 2 The handshake phase includes the sharing ofboth the server certificate and a symmetric algorithm keyHandshake messages are sent in plain text until the serversuccessfully transmits the certificate to the client In thiscontext data transfer is protected by a symmetric cipher

These plain text messages in the handshake phase areparticularly targeted by attackers threatening HTTPS secu-rity Attackers exploit a loophole by impersonating the webserver and stealing user information this approach capitaliseson the userrsquos habit of typing a Uniform Resource Locator(URL) without specifying HTTPS Attackers deceive theclient by making it appear that the web server is using HTTPwithout security Such attacks are known as Man-in-the-Middle (MITM) sniffing and stripping attacks

HindawiSecurity and Communication NetworksVolume 2017 Article ID 9479476 15 pageshttpsdoiorg10115520179479476

2 Security and Communication Networks

In simple terms a web server is identified by the webbrowser using Internet Protocol (IP) The browser obtainsthe serverrsquos IP address from a Domain Name System (DNS)server by sending a DNS query which contains the domainname (DN) The DNS server replies with the server IPand the browser program then sends an HTTPS requestwith the destination IP set to this server IP In the interestsof safety HTTPS secures client-server communication byencrypting HTTP However attackers can take advantageof the unsecured DNS communication by spoofing theseDNS messages and replacing the server IP with the attackerrsquosIP The web browser then sends an HTTPS message to theattackerrsquos IP as the destination server If the attacker deploysa website to answer the client request then the attack isundetected Such attacks are known as DNS spoofing orphishing [2]

The main contributions of this paper to network securityare as follows

(i) We address the question of how to protect the privacyof the user while browsing the Internet To this endwe present the Enc-DNS-HTTP scheme which pro-tects a user surfing the Internet from attacks by encry-pting both DNS andHTTPmessages using asymmet-ric and symmetric cipher algorithms

(ii) Theproposed scheme can resistMITMdisclosure sni-ffing and stripping attacks against the communicationbetween the client and the web server

(iii) The proposed scheme prevents an attacker frommodifying the real web server IP through a DNSattack

(iv) The scheme is applicable to and compatible with curr-ent Internet hardware infrastructureWithin this con-text DNS and HTTP messages are maintained with-out affecting functionality

(v) In terms of computational cost the scheme is shownto outperform HTTPS for high performance value

The remainder of this paper is structured as followsSection 2 provides preliminary and contextual informationSection 3 defines the problem addressed in this workSection 4 describes prior work related to this issue Section 5explains the proposed scheme Section 6 presents the imple-mentation of the Enc-DNS-HTTP scheme in detail Section 7presents the experiments carried out to verify this schemeSection 8 presents the results of experiment and a discussionSection 9 explains the security analysis carried out and thefinal section presents the conclusion

2 Preliminaries

21 Notations

211 Entities Network communication consists of a client(119862) web server (WS) DNS server (DS) and attacker (ATT)When masquerading as a WS the attacker is denoted asATT[WS] whenmasquerading as a119862 the attacker is denotedas ATT[119862] All entities are connected through the Internet

except when ATT is on the same Local Area Network (LAN)as either 119862 or 119878 The Internet gateway is the router (119877)

The Browser Authority (BA) is the creator of the client-side browser program which has both private and publickeysThe public key is distributed to the client by the browser

212 Exchanged Messages

(i) Msg represents a random message For example aterm that 119862 sends as a Msg to WS is denoted asfollows

119862 997888rarrWS Msg (1)

(ii) The term that 119862 sends as a Msg to WS called 119884 andcontaining 119885 is denoted as follows

119862 997888rarrWS 119884 (119885) (2)

213 Parameters Aparameter generated by119862 is expressed as119883119862 and this means that the119883 parameter is created by 119862 Theparameter notation is shown in Notations section

214 Functions The function notation is shown inNotationssection It should be noted that symmetric ciphers use thesame key for different functions such as encryption and dec-ryption whereas an asymmetric cipher uses public or privatekeys for the same functions of encryption and decryptionFor simplicity we distinguish asymmetric encryption anddecryption as we would symmetric encryption and decryp-tion in which each uses a separate key

22 HTTPS Internet privacy is provided by securing theHTTP connections between web browsers and web serversthis is known as HTTPS

221 HTTP HTTP is used to access data on theWorldWideWeb (WWW) and is used as the protocol for data commu-nication HTTP transactions use the services of TransmissionControl Protocol (TCP) on port 80 where the primary HTTPmessages are requested and responses are received betweenclient and server HTTP does not support security and is astateless protocol [3]

222 SSLTLS The SSL protocol and its successor the TLSprotocol are standardised protocol suites which were intro-duced by Netscape in 1995 to provide secure communicationbetween a client and server over an insecure network SSLTLS protects information transmission using a symmetriccipher with a key whose key component is shared by anasymmetric cipher Server authentication is accomplished viadigital certificate by applying X509 technology [4 5]

SSLTLS achieves confidentiality by using encryption itensures integrity through the use of a message authenticationcode which is a hash function with a key and authenticationby a digital certificate A client can validate a server certificateusing the CArsquos public key which is possessed by the client andtypically preinstalled into the web browser [6]

SSLTLS is composed of two layers the upper layer whichcontains the Handshake protocol for establishing a session

Security and Communication Networks 3

Table 1 Establishing a session using the handshake protocol

(M1) CBrarrWS ClientHello (CSL119862 S_ID119862 RN119862)(M2) WSrarr CB ServerHello (CSCWS S_IDWS RNWS)(M3) WSrarr CB Certificate (PKWS sig)

119862 Generate119883119862 random number 119884119862 = Enc(X119862PKWS)SK119862 = 119867 (119883119862 || RN119862 || RNWS)

(M4) CBrarrWS ClientKeyExchange (119884119862)119878119883119862 = Enc(119884119862RKWS) SKWS = 119867(119883119862 || RN119862 || RNWS)

(M5) CBrarrWS ChangeCipherSpec ()(M6) CBrarrWS Finished(Enc(H(SK119862 || Msg_all) SK119862))(M7) WSrarr CB ChangeCipherSpec ()

(M8) WSrarr CB Finished(Enc(H(SKWS || Msg_all)SKWS))

and the Alert protocol for communicating error messagesand application protocols and the lower layer which includesthe Record protocol for exchanging messages using currentconnection parameters obtained from the upper layer [5 7]

The simplest scenario for establishing a session usingSSL is shown in Table 1 where messages (M1) and (M2)define the first phase of SSLTLS The first phase is ciphersuite negotiation which sets and shares the symmetric cipherkey parameters RN119862 and RNWS Message (M3) is the servercertificate that contains the server public key

The second phase is symmetric cipher key constructionwhich is initiated by (M4) Messages (M5) and (M7) com-municate that all further messages will now be encrypted byusing the key and the symmetric cipher previously agreedupon The final phase is secure transmission assuming thatthe nodes manage to decrypt the finished messages TheRecord protocol continues after the final phase until thesession is terminated or destroyed [8ndash10]

23 DNS DNS is a distributed database that translates DNsinto IP addresses The TCPIP suite uses an IP address toroute packets however the host name ismore appropriate forhuman readability [11 12]

As DNs must be globally unique a hierarchical namespace is used as the DN space this is designed in the formof a tree structure with the root at the top Each node in thetree has a label which is a string of characters although theroot label is an empty string However DN is a sequence oflabels separated by dots from the node up to the root

The DN space is distributed across numerous computersknown as DNS servers The division of DN space is basedon the domain which is a subtree of the DN space and issometimes known as the zoneThe name of the domain is thename of the node at the top of the subtree [3]

DNS servers store domain information in a data structureknown as a Resource Record (RR) Each RR has an associatedname class and type AResource Record Set (RRset) describesa situation inwhichmultiple RRs are associatedwith the samename in this case the domain has more than one IP [11]

DNS is designed as a client-server applicationWithin theclient-side application of DNS a resolver receives the DNfrom the browser and sends a mapped request query to the

DNS server The two types of DNS messages are describedbelow [3]

(i) DNS query the resolver creates a DNS query thatcontains an identifier (ID) The ID differs for eachmessage and port number The Question section ofthe DNS query is filled with the DN

(ii) DNS response the server creates aDNS response thiscontains the same ID in order to identify the queryThe Question section contains the DN while theAnswer section contains the IP authoritative sectionand additional information section

DNSmessages are sent without encryption or authenticationthereby increasing the risk of attack DNS is vulnerable tospoofing and cache poisoning attacks which are intended toredirect client traffic to an attackerrsquosmachine or a fakewebsite[13ndash15]

3 Problem Definition

31 Internet Model Internet browsing requires three nodesthe web server the DNS server and the clientTheweb serverhosts the web page as a service to the client The DNS servermaps the host name to the IP as described in Section 2 Theclient is the userrsquos interface to the Internet which runs theweb browser program to handle user requests and serverresponsesWeb browser programs such as IE andChrome arecreated by companies likeMicrosoft andGoogle for exampleIn this work the company which created the browser will bereferred to as the Browser Authority

Each client connects to the Internet through a routerwhich provides the client with an IP119862 DNS IPDS and therouterrsquos own IP119877 as a gateway Internet surfing typically beginswhen the user enters theURL in the CB the browser programthen carries out the following steps

Step 1 CB fetches DN from URL and submits DN to DNSresolver

Step 2 119862 sends Address Resolution Protocol (ARP) requestwith gateway IP119877


Table 2 DNS spoofing attack

ATT within 119862 LAN legitimately ATT must reside between 119862 and 119877(M1) ATTrarr 119862 ARP_Reply (IP119877MACATT) times 119899 ARP poisoning(M2) ATTrarr 119877 ARP_Reply (IP119862MACATT) times 119899

The result is ATT[119877] for 119862 and ATT[119862] for 119877(M3) 119862 rarr ATT[119877] DNS_Query (ID1 DN) dest IP = IPDS

DNS spoofing(M4) ATT[119862] rarr 119877 rarr DS DNS_Query (ID1 DN) dest IP = IPDS

(M5) DSrarr 119877 rarr ATT[119862] DNS_Reply (ID1 DN IPWS) dest IP = IP119862(M6) ATT[119877] rarr 119862 DNS_Reply (ID1 DN IPATT) dest IP = IP119862All client HTTP traffic is sent to ATT directly(M7) 119862 rarr ATT[WS] HTTP_Request (URL) dest IP = IPATT[WS]

(M8) ATT[WS] rarr 119862 HTTP_Response (HTML) dest IP = IP119862

Step 3 119877 responds with its MAC119877 to 119862

Step 4 DNS resolver creates aDNS query containingDN andsends the query in LAN using MAC119877 to the Internet usingIPDS

Step 5 119862 receives DNS reply from DS through 119877 carryingIPWS

Step 6 The resolver delivers IPWS to CB

Step 7 CB creates HTTP request containing URL and sendsthe request through LAN using MAC119877 and through theInternet using IPWS

Step 8 WS responds to 119862 with the service requested such asan HTML page

All DNS and HTTP messages are transferred in plain textwithout the use of an encryption process tomaintain securityand this makes the model vulnerable to various types ofattack

32 Statement of the Problem The problem is how to secureweb browsing or rather how to secure message transfers inthe Internet model A trivial solution is the use of SSLTLSto secure HTTP traffic referred to as HTTPS However thismodel is vulnerable to various attacks and several of these aredescribed further in Section 91

Unfortunately SSL secures HTTP and leaves DNS unse-cured this can then be exploited by DNS spoofing attacks ifATT is in the same LAN as 119862 (Table 2) or by DNS poisoningattack if ATT is on the Internet (Table 3)

During the browsing process even if HTTP transactssecurely using SSL the MITM attack finds a loophole in theprotocol by sniffing and stripping attacks DNSSEC [16] hasbeen proposed in place of SSL for securing DNS messagesand the Internet however this has not been employed dueto its complexity and poor performance as discussed furtherin Section 41

4 Related Work

Protecting web browsers from attackers has attracted agreat deal of research attention due to the plethora of datatransactions and information on the Internet SSLTLS hasbeen deployed for securing HTTP transactions and hasbeen the focus of both developers and attackers worldwideSSL vulnerabilities have been known for several years andseveral suggestions have emerged in the literature for replac-ing modifying or complementing SSLTLS The primaryapproaches which have been proposed for web security canbe categorised as follows

41 Utilising DNS The approaches in this category securethe web through the use of the DNS server which is partof the infrastructure of the Internet DNSSEC was createdto secure DNS messages and to protect the web from majorattacks such as DNS spoofing and has been proposed foruse in sharing web server public keys However DNSSECsuffers from certain problems which have hindered its wideradoption [11]

DNSSEC uses various signature algorithms and hashfunctions however no standard has been agreed on for thespecification of a single algorithm or function Consequentlythe DNS server sends to the client resolver a response con-taining all the keys and signatures which are supported thisresults in higher consumption of bandwidth and processingtime and lower performance The authors of [17] have pro-posed a cipher suite negotiation which selects the strongestalgorithm from the DNS server list as the negotiation para-meter This is then sent in plain text which places the com-munication at risk of a MITM attack which tricks both clientand server into using a weak algorithm by changing the clientlist after which it would be straightforward for the attacker tobreak the security

DANE [18] and CAA [19] are IETF standards that pro-pose the use of DNS infrastructure to validate web servercertificates DANE is a method based on the use of DNSSECwhile CAAmay useDNSSEC as an optionDANE is thereforeaffected by all the vulnerabilities of DNSSEC Both standards


Table 3 DNS cache poisoning attack

ATT not in 119862 LAN ATT must redirect the traffic to his machineATT opportunity if local DS does not have IPWS then the request is sent to zoneserver(M1) 119862 rarr DS119871 DNS_Query (ID1 DN) dest IP = IPDSL

(M2) DS119871 rarr DS119885 DNS_Query (ID2 DN) dest IP = IPDSZ

DNS cache poisoning (Until ID119894 = ID2)(M3) ATT[DS119885] rarr DS119871 DNS_Reply (ID119894 DN IPATT) dest IP = IPDSL times 119899

(M4) DS119871 rarr 119862 DNS_Reply (ID1 DN IPATT) dest IP = IP119862All client HTTP traffic is sent to ATT directly(M5) 119862 rarr ATT[WS] HTTP_Request (URL) dest IP = IPATT(WS)


are used to authenticate website certificates meaning thatthey cannot dispense SSLTLS while browsing the InternetIn addition transfer of the public key remains in plain textmeaning that it can still be forged using a MITM attack

42 Improvement or Enhancement on the Existing SSLTLSAlthough SSLTLS has been proposed for securing HTTPmessages as described in Section 2 attackers have discoveredvulnerabilities [20] The majority of attacks on SSLTLSdo not target the cryptographic core but instead exploitprotocol vulnerabilities or intercept communicating nodes asin MITM

Typing the URL without HTTPS is a bad habit by userswhich exposes the communication to a stripping MITMNumerous enforcement mechanisms have been proposed toprevent the success of MITM attacks such as SHS-HTTPS[21] ISAN-HTTPSEnforcer [22] andHTTPSLock [23] all ofwhich use client-side scripting to redirect the URL to HTTPSbefore sending the request However although this scriptenforces the request it does not enforce the response whichmay be from an attacker

SSLock [24] and HSTS [25] use extra header fields whichare attached by the web server but few browsers or webservers support such method The HTTPS enforcementtechnique is immune to stripping MITM attacks howeverprotection from sniffing MITM attacks rests on the browserwhich displays a warning message indicating a self-signedcertificate At this point most users opt to accept by pressingthe ldquosaferdquo button and this is another bad habit

Aziz et al [26] proposed extending TLS for integrityassurance against replay attacks and collusion attacks byusing the Trusted Platform Module (TPM) TPM is a built-in hardware security chip embedded in the motherboardand is separate from the central processing unit (CPU)TPM includes cryptographic mechanisms for both host andprogram securityThis approach is based on a hardware solu-tion which is not available to every user and affords limitedprotection

Elgohary et al [27] have proposed an enhancement forSSLTLS protocols by caching or storing a client session forfuture use rather than repeating the entire communicationprocess However the enhancement only benefits perfor-mance and not security

5 The Proposed Scheme (Enc-DNS-HTTP)

Theobjective of this work is to secure Internet data transfer bysecuringweb browsing orHTTPmessagesThe term ldquosecurerdquorefers to encryption and authentication which can withstandattacks

In order to meet this objective the proposed schemedistributes PKWS using a DNS server with BA authenticationThe client and web server establish a session using PKWSAt the beginning of the session the two nodes negotiate thesymmetric cipher technique and the key value to be usedThe information is transferred securely using the agreedauthenticated key and techniques

The proposed scheme does not change the Internet deviceinfrastructure or the messaging procedure and browsingcontinues to begin with DNS queries followed by HTTPmessages The proposed changes will be in the messagecontents where we assume the following

(i) BA has PKBA RKBA and PKDS(ii) DNS server has PKDS and RKDS DNS server pos-

sesses PKBA(iii) Every web server must have DNWS IPWS PKWS

RKWS and PKBA(iv) The client has PKBA through the browser and PKDS

from the Internet Service Provider (ISP) during IPconfiguration

Enc-DNS-HTTP consists of two phases registration andInternet browsing and these are described below

51 Registration Phase Web servers must be registered in aDNS server before they can be accessed through the Internetby clients WS sends an encrypted request to BA whichcontains PKWS Next BA signs PKWS and sends an encryptedmessage toDS where the term ldquosignrdquomeans to encrypt PKWSusing RKBA The detailed registration protocol is describedin Table 4 Then WS information is stored in DS as DNWSwhereas BA has signed both IPWS and PKWS The sequenceof the protocol is shown in Figure 1

52 Internet Browsing Phase The Internet browsing phaserefers to the client surfing the Internet The protocol shown


Table 4 WS registration protocol

WS Buf = Enc (PKWS DNWS IPWS PKBA)(M1) WSrarr BA Join_Request (Buf)

BA Dec (Buf RKBA) = PKWS DNWS IPWS

BA Buf = Enc (DNWS IPWS PKDS)(M2) BArarr DS Enquiry (Buf)

DS Dec (Buf RKDS) = DNWS IPWS

DS

Search the database for DNWS IPWSIf found then

Inq = RejectElse

Inq = AcceptBuf = Enc (Inq PKBA)

(M3) DSrarr BA Response_Enquiry (Buf)

BA

Dec (Buf RKBA) = InqIf Inq == Reject then

Jr = RejectBuf = Enc (Jr RKBA)

(M4) BArarrWS Join_Response (Buf)Else

Jr= Acceptbuf1 = Enc (IPWS PKWS RKBA)Buf = Enc (DNWS buf1 PKDS)

(M4) BArarr DS Join (Buf)

DSDec (Buf RKDS) = DNWS buf1Store the value in the databaseBuf = success

(M5) DSrarr BA Join_Reply (Buf)(M6) BArarrWS Join_Response (Buf)

1- Join_Request

6- Join_Response

Keys PKWSRKWS PKBA

WS DNWS IPWS 2- Enquiry

3- Response_Enquiry

4- Join

5- Join_Reply

BAKeys PKBARKBA PKDS

DSKeys PKDSRKDS PKBA

Figure 1 Registration phase

in Table 5 presents the details of the Internet browsing phasewhich begins by entering a URL in CB CB then sends DNWSto the DNS resolver programThe resolver then extracts IPDSfrom the network setting encrypts DNWS using PKDS andsends a query to DSThe reply carries IPWS and PKWS signedby BA whereas the client obtains IPWS and PKWS by usingPKBA which is stored in CB

Inmore detail the process is as follows CBs generate RN119862with CSL encrypt them with PKWS and send the result as anHTTP message to WS using IPWS Next WS generates RNWSencrypted with CSC and sends it to 119862 The hash functionvalue fromRN119862 and RNWS is SK for both sides119862 uses SK119862 toencrypt theHTTP request message andWS uses SKWS twicein decrypting the client request and sending the encrypted


Table 5 WS Internet browsing protocol

119862 Open CB user types a URL119862 CB extracts DNWS and delivers DNWS to the resolver119862 Buf = Enc (DNWS PKDS)

(M1) 119862 rarr DS DNS_Query (Buf)

DS

Dec (Buf RKDS) = DNWSSearch the database for DNWSIf not found then

Buf = Not found(M2) DSrarr 119862 DNS_Reply (Buf)

ElseBuf = Fetch values from DNS database

(M2) DSrarr 119862 DNS_Reply (Buf)119862 Dec (Buf PKBA) = IPWS PKWS

119862 Generate RN119862119862 Buf = Enc (RN119862 CSL PKWS)

(M3) 119862 rarrWS HTTP_RNC (Buf)WS Dec (Buf RKWS) = RN119862 CSLWS Generate RNWS

WS SKWS = H(RN119862 || RNWS)WS Buf = Enc (RNWS CSC RKWS)

(M4) WSrarr 119862 HTTP_RNS (Buf)119862 Dec (Buf PKWS) = RNWS CSC119862 SK119862 = H(RN119862 || RNWS)119862 Buf = Enc (URL SK119862)

(M5) 119862 rarrWS HTTP_Request (Buf)WS Dec (Buf SKWS) = URLWS Buf = Enc (info SKWS)

(M6) WSrarr 119862 HTTP_Response (Buf)119862 Dec (Buf SK119862) = info

If there are no further messages destroy session and delete SK119862 and SKWS

response to119862 If no furthermessages are transmitted between119862 and WS then both sides will delete SK The sequence usedby this protocol is illustrated in Figure 2

6 Implementation

Ubuntu Linux 1204 LTS [28] is used as a platform for imp-lementation and experimentation The proposed scheme isimplemented with 119862 programming language which allowsnetwork programming through the socket library HTTPand DNS servers are implemented separately to be flexibleand to manage DNS query and HTTP request programsimplemented separately on the client side For the purposeof ignoring user delays when typing URL the client-sideprogram reads URL from a file

61 Cryptography Programs RSA and SHA1 algorithms areimplemented according to [29] RSA key generation imple-mented stored each key in a different file to manage anddistribute server keys SHA1 result was stored in a file whichrepresented the symmetric cipher key

The 119862 program code for triple DES was from OpenSSL[30] to make a fair comparison with SSL Cipher BlockChaining (CBC) was utilised for triple DES operation modeTriple DES uses three different 64-bit keys which wereprovided by the keys derived from SHA1 result file

The output of the cryptography algorithm is usuallyambiguous unrecognized characters which were compen-sated for by the implementation programs that read andtransferred the results as hexadecimal numbers

62 DNS Programs DNS is divided into server-side andclient-side programsThe server-side program listens on port53 for incoming queriesWhen a client query arrives carryingDNWS the server replies with Enc(IPWSRKBA) in the answersection and Enc(PKWS RKBA) in the additional section ofthe message

The client-side program sends a DNS query thisfetches DNWS from the URL file creates a DNS queryand sends the query to the host whose IP is saved inthe resolvconf file Following this the client-side programreceives a DNS reply and extracts Enc(IPWSRKBA) andEnc(PKWSRKBA) from the server reply message Finally the


3- HTTP_RNC4- HTTP_RNS

5- HTTP_Request6- HTTP_Response

CKeys PKDS PKBA

DS

Keys PKDSRKDS PKBA

WSKeys PKWSRKWS PKBA

1- DNS_Query

2- DNS_Reply

Figure 2 Internet browsing phase

client-side program performs Dec(Enc(IPWSRKBA)PKBA)andDec(Enc(PKWSRKBA)PKBA) to extract IPWS and PKWSwhich are delivered to the HTTP client program

63 HTTP Programs HTTP is programmed on both the ser-ver and client sides The HTTP server listens on port 80and has two response messages The first message is theresponse to the client RN119862 which is RNWS These twovalues are protected using RSA with Enc(RN119862PKWS) andEnc(RNWSRKWS) When RN119862 and RNWS are entered inthe SHA1 algorithm the symmetric key file SK is producedon both sides The second message contains the requestedservice such as an HTML page and this service is encryptedusing the symmetric cipher agreed on in the previousmessagewith SK

The HTTP client-side program uses IPWS received fromthe DNS server to set the destination address The clientprogram has two main messages The first negotiates thesymmetric cipher algorithm to be used with the server andshares the key parameterThe second message reads the URLfrom the URL file encrypts the request using SK and sendsanHTTP request to the server Finally the client decrypts thereceived content from the server using SK and saves the resultin a file

7 Experimental Testing

A network with five hosts was built to test the Enc-DNS-HTTP protocol Four hosts ran the Ubuntu Linux operatingsystem whereas one host ran Kali Linux [31] in order touse the attacker programs and tools The first Ubuntu hostrepresented WS this ran the HTTP server-side program andpossessed the cryptography programs The second Ubuntuhost represented DS and ran the DNS server-side program

The third Ubuntu host operated as the client this con-tained the DNS client program the HTTP client programand all cryptography programsThe client programs togethermade up CB The final Ubuntu host had three networkconnections in order to simulate the router enable theIP_forward property for directing the packet to the correctnetwork interface connect all hosts to different IPs to sim-ulate each host in a different network enable DHCP-setting

for the assignment of theDNS IP and save IP in the resolvconffile

The client and the attacker were connected to the sameLAN as illustrated in Figure 3 Table 6 shows the hostproperties and contents Prior to the experiment all serverkeys were created using RSA key generation and stored indifferent files It was assumed that the registration phase in theproposed scheme had been executed earlier since this phaseruns only once for each WS

WS was installed with the Apache 24 HTTP server [32]and 119862 was installed with the Curl 7 web browser [33] forthe purpose of comparing results WS was loaded with fiveHTMLpages of different sizes (a)HTML 100Byte (b)HTML1KB (c) HTML 10KB (d) HTML 100KB and (e) HTML1MB Each page was called four times in order to calculatethe average time for the experiment Wireshark software [34]was used for the capture and analysis of traffic

In this experiment the robustness of the proposed Enc-DNS-HTTP was tested under two conditions firstly withoutan attack and then with an attack The first conditionrepresents the unsecured mode of Apache HTTP the HTTPprogram Apache HTTPS and Enc-DNS-HTTP whereas thesecond illustrates Apache HTTPS and Enc-DNS-HTTP insecure mode

The experimental results from the proposed schemein a real multisession are reported for the five differentHTML pages These pages were called four times under bothconditions and the performance of the proposed scheme wasevaluated in terms of efficiency and effectiveness The stepsinvolved in the experimental procedure were as follows

(i) Start the Wireshark program in WS DS and 119862

(ii) Start the DNS and HTTP servers

(iii) Use CB to call five pages four times each within1min

(iv) Stop the DNS and HTTP servers

(v) Stop the Wireshark program and save the packetscaptured in a file


Table 6 Properties and contents of hosts

HostndashInterface Properties ContentsIP MAC Parameter files Programs

WS ndash eth0 192168332 000c293afece PKWS RKWS PKBA(i) HTTP server(ii) Cryptography programs

DS ndash eth0 192168222 000c290502ac PKDS RKDS PKBA(i) DNS server(ii) Cryptography programs

C ndash eth0 1921681120 000c294d6cdb PKBA PKDS

(i) DNS client(ii) HTTP client(iii) Cryptographyprograms

ATT ndash eth0 1921681121 000c29c4df81 PKBA PKDS

(i) ARP spoofing(ii) DNS spoofing(iii) SSL stripping

R-eth0 192168111 000c29b20005-eth1 192168221 000c29b2000f-eth2 192168331 000c29b20019

C 1921681120

ATT 1921681121

Switch

RouterR

eth0

R1 192168111DHCP enable

R2 192168221

Internet

R3 192168331

eth1

eth2

DS 192168222

WS 192168332

Figure 3 Experimental network

This procedure was executed without attack for ApacheHTTP programmed HTTP Apache HTTPS and Enc-DNS-HTTP In the attack situation run for HTTPS and Enc-DNS-HTTP CB called each of the five pages once and ATT ran theWireshark program to capture network packets

71 Attacker Models The DNS spoofing attack procedureused was as follows

(1) ATT connects to the LAN network and obtains an IPfrom 119877

(2) ATT runs ARP poisoning to redirect packet transfersto his computer ARP poisoning is performed bysending periodic ARP replies to 119862 and 119877

(3) ATT runsDNS spoofing to change IPWS inDNS replyif DNWS in the packet matches DN in a file ATTmustknow DN in advance

(4) If DNWS matches IPWS is changed to IPATT in thisexperiment this led to a DoS as ATT did not imple-ment a web page Otherwise the packet is forwardedto its destination

The SSL stripping attack procedure used was as follows



(3) ATT runs SSL stripping to identify HTTPS trafficfrom 119862 and forwards it to WS When WS respondswith HTTPS ATT deceives 119862 and responds withHTTP to 119862

119862 obtains service through HTTP rather than HTTPS andATT can read and modify all information from 119862

8 Results and Discussion

The results indicate the robustness of Enc-DNS-HTTP thescheme is implemented using the 119862 programming languageand focused on the essentials of Internet browsing A com-parison of this scheme with Apache HTTPS is inappropriatesince the Apache server is built on complex procedures which


require more time to execute The results show that normalbrowsing with 119862 programming language and the ApacheHTTP server results in at least an approximate machinedelay difference which can be applied to encrypted browsingsituations

The results of this experiment show that Apache HTTPand programmed HTTP performed similarly in terms ofoperation time and media delay in unsecured conditionsIn contrast Enc-DNS-HTTP performs better than ApacheHTTPS in the secure condition In other words Enc-DNS-HTTP can ensure the privacy of information transfer withinthe network

In the discussion of the results given below the termldquonormal HTTPrdquo is used to refer to the programmed HTTPimplemented without encryption and the normal HTTPApache server ldquoEncrypted HTTPrdquo refers to the programmedHTTP implemented with encryption as Enc-DNS-HTTP aswell as HTTPS run using the Apache server ldquoEncryptedHTTP under attackrdquo refers to encrypted HTTP attacked byDNS spoofing

81 DNS Messages The messages between 119862 and DS areexclusively DNS messages Figure 4 shows the DS machinersquosaverage time delay which is calculated from 20 DNSqueryndashreply pairs except for the attack situation which iscalculated from five DNS queryndashreply pairs Figure 5 showsthe media average time delay calculated for each DNSqueryndashreply pair from the client side The time differencebetween reply and query messages minus the DS machinersquostime is the media delay

Normal HTTP showsminimal difference in Figure 4 dueto the message sizes given in Table 7 A large variation inmachine timing is observed in the encrypted HTTP sinceEnc-DNS-HTTP uses cryptographic programs Moreoverthe message size is large since PKWS is assigned to the addi-tional section of the reply However since Apache HTTPSdoes not encrypt DNS messages the value is approximatelyequal to that of normal HTTP

Figure 4 clearly shows that the protocol proposed in thiswork requires more time due to the use of the encryptionprocess The additional time cost of this scheme may beconsidered reasonable in order to achieve the security of DNSmessages

In the attack situation no differences in terms of timewere observed in the encrypted HTTP caused by the DSmachine delay However media delay was affected as shownin Figure 5 since DNS messages pass through the attackingmachine causing an additional delay The DNS spoofingattack is based on a list of DNs stored in a file and the DNis compared for each reply message If one matches the IP isthen replaced in this attack procedure the media delay forHTTPS becomes large in the process of replacing IPWS valueIt should be noted that the attacker cannot identify DN in thereply message when using the proposed scheme since DN isencrypted with PKDS and only DS can produce the correctDN

Under the proposed scheme the DNS reply message isreceived by 119862 carrying IPWS whereas in Apache HTTPS119862 carries the fake IP of the attacker Although the DS

052

4745

296

5

280

24

063

435

059

58

056

0366

667

Normal HTTP Encrypted HTTP Encrypted HTTP under attack

ProgramsApache

0

05

1

15

2

25

3

35

Aver

age t

ime d

elay

(ms)

Figure 4 DS machine average time delay

656

8

079

69

074

565

075

12

071

915

2840482333

Encrypted HTTP under attack

Normal HTTP Encrypted HTTP

ProgramsApache

0

50

100

150

200

250

300Av

erag

e tim

e del

ay (m

s)

Figure 5 Average media time delay between 119862 and DS

machine time is increased with the use of Enc-DNS-HTTPthis scheme protects the browser from attack

Again as can be seen in Figure 5 the Apache HTTPSinduces a higher delay since the time taken for the ATT tofind the DNWS match in the DNS response and subsequentlyreplace IPWS with IPATT causes a delay in the response

82 TCP Messages 119862 and WS communicate through TCPmessages which carry user requests in the form of URLsWS responds throughHTMLThe average time delays for theWSmachine shown in Figure 6 demonstrate that Enc-DNS-HTTP is superior even under attack No curve is shown forApache HTTPS in an attack situation since this is vulnerableto the attack causing a DoS for 119862

Figure 6 indicates that the page size affects the WSdelay After the fourth page machine delay scatters andApache requires the largest time for both HTTP and HTTPS


Table 7 Sizes of DNS messages

Programmed HTTP Apache HTTP Programmed Enc-DNS-HTTP Apache HTTPSQuery message size (bytes) 68 75 91 75Reply message size (bytes) 84 91 125 91

ahtml bhtml chtml dhtml ehtml

Programs HTTPApache HTTPEnc-DNS-HTTP

Apache HTTPSEnc-DNS-HTTP under attack

0

05

1

15

2

25

Aver

age t

ime d

elay

(Sec

)

Figure 6 Average time delay for WS machine

The delay time of Enc-DNS-HTTP under attack is due solelyto the use of ARP poisoning by the attacker before DNSspoofing this sends ARP replies to WS creating additionaltasks for WS The curve for Enc-DNS-HTTP in Figure 6clearly shows that the process of an attack has no effect onour scheme

Figure 7 shows increases in media delay when Enc-DNS-HTTP is under attack in this case packets pass throughthe attackerrsquos machine adding an extra delay The attackerforwards only TCP messages as he cannot identify DNwhich is encrypted The performance of both the ApacheHTTPS and our scheme within the framework at transmis-sion time is evaluated as shown in Figure 7 The differencesin time delay illustrate that the proposed scheme is fasterthan Apache HTTPS this is due to the lower number ofnegotiation messages required by the proposed scheme

HTTPS shows a higher media delay than Enc-DNS-HTTP due to the number of messages transferred withinthe Handshake protocol Enc-DNS-HTTP requires only twomessages whereas HTTPS requires eight as discussed inSection 222 The number of handshake messages affectsthe WS machine time this can be seen in Figure 8 whereHTTPS has the largest value Figure 8 also demonstrates thecorrectness of the proposed scheme in terms of server loadAs expected our scheme has a lower impact on machinedelay with increasingmessage size since it employs few time-consuming operations unlike Apache HTTPS

Thus Apache HTTPS and Enc-DNS-HTTP are testedon the same types of pages carried by TCP These testsshow that the number and size of negotiation messages have

ahtml bhtml chtml dhtml ehtml0

01

02

03

04

05

06

07

08

09

1

Aver

age t

ime d

elay

(Sec

)Programs HTTPApache HTTPEnc-DNS-HTTP


Figure 7 Average time delay for the media between 119862 and WS


5

10

15

20

25

30

35

40

Aver

age t

ime d

elay

(ms)

Enc-DNS-HTTPApache HTTPS

Enc-DNS-HTTP under attack

Figure 8 Average time delay for WS machine (handshake only)

a large influence over the results leading to Enc-DNS-HTTPoutperforming Apache HTTPS

83 Throughput The throughput of both our scheme andApache is evaluated in three cases normal encrypted andencrypted under attack As can be seen in Figure 9 in the firstcase both methods are comparable with average throughputhowever in the second case the difference is clear consideringthe DNS message size The third case illustrates that our



ProgramsApache

0

20

40

60

80

100

120

140

Aver

age t

hrou

ghpu

t (KB

S)

Figure 9 Throughput between 119862 and DS

work is free from breach by attack and that it induces betterthroughput than Apache

The difference in throughput between 119862 and DS shownin Figure 9 is due to the size of the message Enc-DNS-HTTP has larger DNS messages than HTTPS resulting in areduced throughput Attacker interception reduces through-put increasing the packet time delay since the throughputof Enc-DNS-HTTP is higher than that of Apache this isfurther confirmation that the attacker did not modify thereply unlike in the case of HTTPS

Combining the DNS and TCP message sizes and con-sidering the requestndashresponse delay from 119862 side gives sys-tem throughput as presented in Figure 10 Securing HTTPwill reduce system performance which leads to decreasedthroughput Although DNS spoofing lowers throughput theattacker cannot break browsing securitywith fake IP in aDNSreply However when Apache HTTPS is used the attackercanmanipulate the DNS replies with a fake IP resulting in noHTTPS response this gives an infinite delay and a throughputequal to zero

In summary the entire protocol is analysed here in orderto test its performance in terms of average throughput theproposed scheme clearly has better throughput than ApacheIn addition the security ability of the proposed scheme istested our scheme performed well under the well-knownApache HTTPS attacks since this scheme secures DNSmessages and shares the WS public key unlike Apache

Enc-DNS-HTTPwithstandsDNS spoofing and SSL strip-ping attacks which read the HTTPS requestndashresponse pro-cess between 119862 and WS With Enc-DNS-HTTP the attackercannot deceive119862 and redirect to HTTP since the first requestis encrypted

9 Attack Definitions and Security Analysis

In this section an illustration of the most well-known attacksthat threaten web browsing security is presented Following



ProgramsApache

0

200

400

600

800

1000

1200

1400

1600

1800

Aver

age t

hrou

ghpu

t (KB

S)

Figure 10 System throughput

this the security of the proposed scheme will be describedand analysed

91 Attacks The theft of sensitive data from users is one ofthe most frequent objectives pursued by attackers Numerousmethods are employed to tempt users into providing theirdata over the wrong connection which leads to the attackerrsquosdestination rather than the legitimate destination

HTTPS offers one defence against web attacks but thissuffers from vulnerabilities [35] However the goal of attack-ers is generally to impersonate the server rather than to crackHTTPS keys The attacker intercepts traffic from the sourceand forwards it to the destination (and vice versa) creatingan illusion of the user and server being connected normallywhen in fact the attacker can modify messages and insertnew ones The most well-known attacks are detailed in thefollowing subsections [36 37]

911 MITM According to RFC 2828 a MITM attack isldquoa form of active wiretapping attack in which the attackerintercepts and selectively modifies communicated data inorder to masquerade as one or more of the entities involvedin a communication associationrdquo In a virtual sense the atta-cking machine is placed between two communicating com-puters giving the attacker the capability to read modify orblock information The original computers believe they areconnected only to each other and neither the user nor theserver is aware of the MITM [38 39]

According to [22 40] the MITM attack may employtwo methods ldquostrippingrdquo and ldquosniffingrdquo In MITM sniffinga forged self-signed certificate is presented to the victim asa legal web server certificate After the user accepts the fakecertificate the userrsquos information is compromised HoweveraMITM stripping attack changes anHTTPS connection withthe victim to HTTP and connects with the web server usingHTTPS The use of the HTTP connection causes the victimrsquosinformation to be transferred in plain text format


912 Denial of Service (DoS) The growing number of DoSattacks imposes a significant threat to the availability ofnetwork services A DoS attack is characterised by maliciousbehaviour which prevents legitimate users of a networkservice from using that service [41 42] There are twoprincipal types of DoS attack The first is a flooding attackwhich sends an excessive quantity of packets to a client victimThese packets arrive in such high quantity that a certain keyresource at the victim (bandwidth buffers or CPU time tocompute responses) is quickly depleted The victim machineeither crashes or spends so long compensating for attacktraffic that it cannot attend to its real work [43] The secondtype ofDoS attack starts as aMITMattack however when theattack blocks the packets sent to the client the attack becomesa DoS

92 Security Analysis

Theorem 1 Enc-DNS-HTTP is protected from DNS spoofingattack

Proof As mentioned in Section 71 in order to accomplishDNS spoofing the attacker must knowDNWS in advance andstore this in a file Enc-DNS-HTTP sends encrypted DNWSusing PKDS in DNS query and WS replies with the sameencrypted DNWS as shown in the (M1) and (M2) messagesin Table 5 The encryption of DNWS means that DNWS willnot match the DN known by ATT

Theorem 2 If the DNS spoofing attack stores the encryptedDNWS then Enc-DNS-HTTP will not disclose 119862 information

Proof ATTmay have PKDS since ATT is on the same LAN as119862 If ATT encrypts a list of DN and stores the ciphered DN ina DNS spoofing file then the website will be identified fromthe 119862 query since both 119862 and ATT possess PKDS ATT savesthe DNS query ID119862 and compares the ID of all DNS replieswith ID119862 Once ATT finds the matchingdesired websiteATT can change IPWS119862 will then suffer from DoS since 119862 will decrypt IPWS

from the DNS reply as shown in message (M2) in Table 5leading to a random IP The HTTP request will receive noresponse leading to DoS ATT can achieve DoS but cannotread the information of 119862

Theorem 3 A DNS spoofing attack is unable to replace IPWSwith a legal IP

Proof ATT can read both the DNS reply and IPWS bydecrypting with PKBA which accompanies CB HoweverATT cannot replace IPWS with a real IP since ATT does nothave RKBA to reencrypt the desired IPATT

Theorem4 Enc-DNS-HTTP is protected fromDNS poisoningattack

Proof Table 3 shows that DNS cache poisoning attacksdepend on guessing ID2 when IPWS is stored in a regularformat However in Enc-DNS-HTTP IPWS is encrypted withBA authentication using RKBA when saved as illustrated by

message (M3) in Table 4 If ATT is lucky and guesses ID2the stored record will be corrupted because PKWS is an emptyfield thus the IP does not lead to WS for 119862

Theorem 5 Enc-DNS-HTTP prevents a MITM attack fromdisclosing 119862 information

Proof As described in Section 71 the first step for an ATT isto execute ARP poisoning in order to reside in a virtual sensebetween 119862 and 119877 this results in both 119862 and 119877 sending allnetwork packets through ATT From the 119862 standpoint ATTmasquerades as 119877 from the 119877 standpoint ATT masqueradesas 119862 However even if all packets pass through ATT ATTcannot read or forge any information since the information isencrypted using an asymmetric cipher119862 encrypts data usingPKDS for sending to DS and encrypts data using PKWS forsending to WS In both steps ATT is unable to read the dataas ATT has neither RKDS nor RKWS 119862 and WS agree on asymmetric algorithm and this is the key to guaranteeing theprotection of the information

Theorem 6 Enc-DNS-HTTP is protected from a MITMstripping attack

Proof As described in Section 71 in MITM stripping ATTwill identify HTTPS traffic and change it to HTTP ATT willforward a packet from 119862 receive the WS response decryptthe response and send anHTTP response to119862 In Enc-DNS-HTTP ATT cannot perform the second stage because he doesnot have PKWS which is obtained by 119862 from DS

Theorem 7 Enc-DNS-HTTP is protected from a MITMsniffing attack

Proof As described in Section 911 MITM sniffing attackscircumvent HTTPS by presenting a forged certificate afterwhich ATTwaits for acceptance by119862 With Enc-DNS-HTTPATT cannot forge PKWS without RKBA andATTmust poisontheDNS cache If ATTdesires to fake IPWS then this becomesa redirection task as demonstrated inTheorems 1 and 2

Theorem 8 Enc-DNS-HTTP supports WS authentication

Proof As described in Section 52 the handshake informa-tion transferred fromWS is encrypted using RKWS which ispossessed only by WS Following this the information fromWS is authenticated

Theorem 9 Enc-DNS-HTTP supports data transfer security

Proof As described in Section 52 data are encrypted beforebeing transferred across the network Both asymmetric andsymmetric encryption are used for the data the symmetrickey is discarded after each session a form of one-timepassword

10 Conclusion

The security of web browsing depends on SSLTLS tosecure a client and web server connection MITM and


DNS attacks threaten the privacy of HTTPS using differentapproaches

This paper proposes Enc-DNS-HTTP to protect web bro-wsing and to secure clientndashDNS server and clientndashweb servercommunications The scheme is based on sharing a webserver public key through the DNS server The key is signedby a trusted third party such as a web browser program crea-tor

The browser program begins by fetching a web serverpublic key from a DNS server and verifying the key througha third party public key (PKBA) Following this the browserprogram sends an encrypted symmetric key parameter tothe web server After receiving the second symmetric keyparameter from the server both sides generate a secret keyFinally the browser program requests the service from theweb server The request is encrypted with the secret key andthe response will be encrypted with the same key

The proposed scheme is implemented in the C program-ming language on a Linux platform The results demon-strate the effectiveness of Enc-DNS-HTTP in protecting webbrowsing In addition throughput shows improved perfor-mance despite the encryption affecting the communicationfrom both the DNS and web servers

Notations

Parameter

PK Public keyIP Internet protocolRN Random numberInfo Information or HTML pageCSL Cipher suite list supported by the client nodeCSC Cipher suite choiceCB Client browser programRK Private keyURL Uniform resource locatorSK Secret keysession keyS_ID Session IDMsg_all All messages exchanged between119862 andWS so farSig Authority signatureDN Domain name

Function

Enc(119883 119884) 119883 is encrypted with key 119884Dec(119883 119885) 119883 is decrypted with key 119885Enc(119883119882119885 119884) Each parameter encrypted separately

with 119884119867(119883) Hashed value of119883119867(119883 119884) Hashed value after concatenating119883 and

119884

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

This work is supported by National 973 Fundamental BasicResearch Program of China under Grant no 2014CB340600

References

[1] Z Ye S Smith and D Anthony ldquoTrusted paths for browsersrdquoACM Transactions on Information and System Security vol 8no 2 pp 153ndash186 2005

[2] A Herzberg and A Jbara ldquoSecurity and identification indica-tors for browsers against spoofing and phishing attacksrdquo ACMTransactions on Internet Technology (TOIT) vol 8 no 4 pp161ndash1636 2008

[3] B A Forouzan TCPIP Protocol Suite McGraw-Hill 4th edi-tion 2010

[4] J Du and G Nie ldquoDesign and implementation of securityreverse data proxy server based on SSLrdquo in Proceedings of theProceedings of International Conference on Communications inComputer and Information Science (ICCIC rsquo11) pp 523ndash528Wuhan China 2011

[5] K Bhargavan C Fournet R Corin and E Zalinescu ldquoVerifiedcryptographic implementations for TLSrdquo ACM Transactions onInformation and System Security vol 15 no 1 article no 3 2012

[6] A Bates J Pletcher T Nichols B Hollembaek D Tian and KR B Butler ldquoSecuring SSL certificate verification through dyna-mic linkingrdquo in Proceedings of the ACM SIGSAC Conference onComputer andCommunications Security (CCS rsquo14) pp 394ndash405ACM Scottsdale Ariz USA November 2014

[7] H Lee T Malkin and E Nahum ldquoCryptographic strength ofSSLTLS servers current and recent practicesrdquo in Proceedingsof the 7th ACM SIGCOMM conference on Internet measurement(IMC rsquo07) pp 83ndash92 ACM San Diego USA Calif USA 2007

[8] C Castelluccia E Mykletun and G Tsudik ldquoImproving secureserver performance by Re-balancing SSLTLS handshakesrdquo inProceedings of the ACM Symposium on Information Computerand Communications Security (ASIACCS rsquo06) pp 26ndash34 IEEETaipei Taiwan March 2006

[9] J GroBschadl and I Kizhvatov ldquoPerformance and securityaspects of client-side SSLTLS processing on mobile devicesrdquoin Proceedings of the 9th International Conference on Cryptologyand Network Security (CANS rsquo10) pp 44ndash61 Springer KualaLumpur Malaysia December 2010

[10] T Saito K Sekiguchi and R Hatsugai ldquoAuthentication bindingbetween TLS andHTTPrdquo in Proceedings of the 2nd InternationalConference on Network-Based Information Systems (NBiS rsquo08)pp 252ndash262 Springer Turin Italy September 2008

[11] H Yang E Osterweil D Massey S Lu and L Zhang ldquoDeploy-ing cryptography in internet-scale systems a case study onDNSSECrdquo IEEE Transactions on Dependable and Secure Com-puting vol 8 no 5 pp 656ndash669 2011

[12] C Shue and A Kalafut ldquoResolvers revealed characterizingDNS resolvers and their clientsrdquo ACM Transactions on InternetTechnology (TOIT) vol 12 no 4 pp 141ndash1417 2013

[13] R van Rijswijk-Deij A Sperotto and A Pras ldquoDNSSEC andits potential for DDoS attacks a comprehensive measurementstudyrdquo in Proceedings of the ACM Internet Measurement Con-ference (IMC rsquo14) pp 449ndash460 ACM Vancouver CanadaNovember 2014

[14] H Wu X Dang L Zhang and L Wang ldquoKalman filter basedDNS cache poisoning attack detectionrdquo in Proceedings of the


11th IEEE International Conference on Automation Science andEngineering (CASE rsquo15) pp 1594ndash1600 August 2015

[15] D Gollmann ldquoSecure applications without secure infrastruc-turesrdquo in Proceedings of the 5th International Conference onMathematical Methods Models and Architectures for ComputerNetwork Security (MMM-ACNS rsquo10) pp 21ndash31 PetersburgRussia 2010

[16] R Arends R AusteinM Larson DMassey and S Rose ldquoDNSsecurity introduction and requirementsrdquo RFC Editor RFC40332005

[17] A Herzberg H Shulman and B Crispo ldquoLess is more cipher-suite negotiation for DNSSECrdquo in Proceedings of the 30thAnnual Computer SecurityApplicationsConference (ACSAC rsquo14)pp 346ndash355 ACM New Orleans La USa December 2014

[18] P Hoffman and J Schlyter ldquoThe DNS-Based Authenticationof Named Entities (DANE) Transport Layer Security (TLS)Protocol TLSArdquo Internet Engineering Task Force RFC 66982012

[19] P Hallam-Baker and R Stradling DNS Certification AuthorityAuthorization (CAA) Resource Record Internet EngineeringTask Force RFC 6844 2013

[20] O Levillain A Ebalard B Morin and H Debar ldquoOne year ofSSL internet measurementrdquo in Proceedings of the 28th AnnualComputer Security Applications Conference (ACSAC rsquo12) pp 11ndash20 ACM Orlando Fla USA December 2012

[21] B Sugavanesh R Hari Prasath and S Selvakumar ldquoSHS-HTTPS enforcer enforcing HTTPS and preventing MITMattacksrdquo ACM SIGSOFT Software Engineering Notes vol 38 no6 pp 1ndash4 2013

[22] S Puangpronpitag and N Sriwiboon ldquoSimple and lightweightHTTPS enforcement to protect against SSL striping attackrdquoin Proceedings of the 4th International Conference on Com-putational Intelligence Communication Systems and Networks(CICSyN rsquo12) pp 229ndash234 Phuket Thailand July 2012

[23] A P H Fung and K W Cheung ldquoHTTPSLock enforcingHTTPS in unmodified browsers with cached Javascriptrdquo inProceedings of the 4th International Conference on Networkand System Security (NSS rsquo10) pp 269ndash274 IEEE MelbourneAustralia September 2010

[24] A P H Fung and K W Cheung ldquoSSLock sustaining the truston entities brought by SSLrdquo in Proceedings of the 5th ACMSymposium on Information Computer and CommunicationSecurity (ASIACCS rsquo10) pp 204ndash213 ACM Beijing ChinaApril 2010

[25] JHodges C Jackson andA BarthHTTPStrict Transport Secu-rity (HSTS) Internet Engineering Task Force RFC 6797 2012

[26] NAzizNUdzir andRMahmod ldquoExtendingTLSwithmutualattestation for platform integrity assurancerdquo Journal of Comm-unications vol 9 no 1 pp 63ndash72 2014

[27] A Elgohary T S Sobh and M Zaki ldquoDesign of an enhance-ment for SSLTLS protocolsrdquo Computers and Security vol 25no 4 pp 297ndash306 2006

[28] Linux Ubuntu httpwwwubuntucom[29] W Stallings Cryptography and Network Security Principles and

Practice Prentice Hall 5th edition 2011[30] OpenSSL httpswwwopensslorg[31] Kali Linux httpswwwkaliorg[32] Apache Web Server httpshttpdapacheorg[33] Curl httpscurlhaxxse[34] Wireshark httpswwwwiresharkorg

[35] A Eldewahi T Sharfi A Mansor N Mohamed and S Alwah-bani ldquoSSLTLS attacks analysis and evaluationrdquo in Proceedingsof the International Conference onComputing Control Network-ing Electronics and Embedded Systems Engineering (ICCNEEErsquo15) pp 203ndash208 IEEE Khartoum Sudan 2015

[36] Y Jia Y Chen X Dong P Saxena J Mao and Z Liang ldquoMan-in-the-browser-cache persisting HTTPS attacks via browsercache poisoningrdquo Computers and Security vol 55 no 1 pp 62ndash80 2015

[37] M Prandini and M Ramilli ldquoA browser-based distributed sys-tem for the detection of HTTPS stripping attacks againstweb pagesrdquo in Proceedings of the 27th IFIP TC 11 Conferenceon Information Security and Privacy (SEC rsquo12) pp 549ndash554Springer Heraklion Greece June 2012

[38] J Du X Li and H Huang ldquoA study of man-in-the-middleattack based on SSL certificate interactionrdquo in Proceedings of the1st International Conference on Instrumentation MeasurementComputer Communication and Control (IMCCC rsquo11) pp 445ndash448 IEEE Beijing China October 2011

[39] D Berbecaru and A Lioy ldquoOn the robustness of applicationsbased on the SSL and TLS security protocolsrdquo in Proceedingsof the 4th European PKI Workshop on Public Key Infrastructure(EuroPKI rsquo07) pp 248ndash264 Springer Palma deMallorca Spain2007

[40] K Cheng M Gao and R Guo ldquoAnalysis and research onHTTPS hijacking attacksrdquo in Proceedings of the 2nd Interna-tional Conference on Networks Security Wireless Communica-tions andTrustedComputing (NSWCTC rsquo10) pp 223ndash226 IEEEWuhan China April 2010

[41] M S Fallah ldquoA puzzle-based defense strategy against floodingattacks using game theoryrdquo IEEE Transactions on Dependableand Secure Computing vol 7 no 1 pp 5ndash19 2010

[42] HWang D Zhang and K G Shin ldquoChange-point monitoringfor the detection of DoS attacksrdquo IEEE Transactions on Depend-able and Secure Computing vol 1 no 4 pp 193ndash208 2004

[43] JMirkovic and P Reiher ldquoD-WARD a source-end defense agai-nst flooding denial-of-service attacksrdquo IEEE Transactions onDependable and Secure Computing vol 2 no 3 pp 216ndash2322005

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Active and Passive Electronic Components

Control Scienceand Engineering

Journal of


International Journal of

RotatingMachinery


Hindawi Publishing Corporation httpwwwhindawicom

Journal of

Volume 201

Submit your manuscripts athttpswwwhindawicom

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics


Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of


Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation



DistributedSensor Networks



In simple terms a web server is identified by the webbrowser using Internet Protocol (IP) The browser obtainsthe serverrsquos IP address from a Domain Name System (DNS)server by sending a DNS query which contains the domainname (DN) The DNS server replies with the server IPand the browser program then sends an HTTPS requestwith the destination IP set to this server IP In the interestsof safety HTTPS secures client-server communication byencrypting HTTP However attackers can take advantageof the unsecured DNS communication by spoofing theseDNS messages and replacing the server IP with the attackerrsquosIP The web browser then sends an HTTPS message to theattackerrsquos IP as the destination server If the attacker deploysa website to answer the client request then the attack isundetected Such attacks are known as DNS spoofing orphishing [2]

The main contributions of this paper to network securityare as follows

(i) We address the question of how to protect the privacyof the user while browsing the Internet To this endwe present the Enc-DNS-HTTP scheme which pro-tects a user surfing the Internet from attacks by encry-pting both DNS andHTTPmessages using asymmet-ric and symmetric cipher algorithms

(ii) Theproposed scheme can resistMITMdisclosure sni-ffing and stripping attacks against the communicationbetween the client and the web server

(iii) The proposed scheme prevents an attacker frommodifying the real web server IP through a DNSattack

(iv) The scheme is applicable to and compatible with curr-ent Internet hardware infrastructureWithin this con-text DNS and HTTP messages are maintained with-out affecting functionality

(v) In terms of computational cost the scheme is shownto outperform HTTPS for high performance value

The remainder of this paper is structured as followsSection 2 provides preliminary and contextual informationSection 3 defines the problem addressed in this workSection 4 describes prior work related to this issue Section 5explains the proposed scheme Section 6 presents the imple-mentation of the Enc-DNS-HTTP scheme in detail Section 7presents the experiments carried out to verify this schemeSection 8 presents the results of experiment and a discussionSection 9 explains the security analysis carried out and thefinal section presents the conclusion

2 Preliminaries

21 Notations

211 Entities Network communication consists of a client(119862) web server (WS) DNS server (DS) and attacker (ATT)When masquerading as a WS the attacker is denoted asATT[WS] whenmasquerading as a119862 the attacker is denotedas ATT[119862] All entities are connected through the Internet

except when ATT is on the same Local Area Network (LAN)as either 119862 or 119878 The Internet gateway is the router (119877)

The Browser Authority (BA) is the creator of the client-side browser program which has both private and publickeysThe public key is distributed to the client by the browser

212 Exchanged Messages

(i) Msg represents a random message For example aterm that 119862 sends as a Msg to WS is denoted asfollows

119862 997888rarrWS Msg (1)

(ii) The term that 119862 sends as a Msg to WS called 119884 andcontaining 119885 is denoted as follows

119862 997888rarrWS 119884 (119885) (2)

213 Parameters Aparameter generated by119862 is expressed as119883119862 and this means that the119883 parameter is created by 119862 Theparameter notation is shown in Notations section

214 Functions The function notation is shown inNotationssection It should be noted that symmetric ciphers use thesame key for different functions such as encryption and dec-ryption whereas an asymmetric cipher uses public or privatekeys for the same functions of encryption and decryptionFor simplicity we distinguish asymmetric encryption anddecryption as we would symmetric encryption and decryp-tion in which each uses a separate key

22 HTTPS Internet privacy is provided by securing theHTTP connections between web browsers and web serversthis is known as HTTPS

221 HTTP HTTP is used to access data on theWorldWideWeb (WWW) and is used as the protocol for data commu-nication HTTP transactions use the services of TransmissionControl Protocol (TCP) on port 80 where the primary HTTPmessages are requested and responses are received betweenclient and server HTTP does not support security and is astateless protocol [3]

222 SSLTLS The SSL protocol and its successor the TLSprotocol are standardised protocol suites which were intro-duced by Netscape in 1995 to provide secure communicationbetween a client and server over an insecure network SSLTLS protects information transmission using a symmetriccipher with a key whose key component is shared by anasymmetric cipher Server authentication is accomplished viadigital certificate by applying X509 technology [4 5]

SSLTLS achieves confidentiality by using encryption itensures integrity through the use of a message authenticationcode which is a hash function with a key and authenticationby a digital certificate A client can validate a server certificateusing the CArsquos public key which is possessed by the client andtypically preinstalled into the web browser [6]

SSLTLS is composed of two layers the upper layer whichcontains the Handshake protocol for establishing a session










































4 Related Work



































DS


Inq = RejectElse



BA








1- Join_Request

6- Join_Response

Keys PKWSRKWS PKBA


3- Response_Enquiry

4- Join

5- Join_Reply










DS













6 Implementation










CKeys PKDS PKBA

DS

Keys PKDSRKDS PKBA


1- DNS_Query

2- DNS_Reply




























C 1921681120

ATT 1921681121

Switch

RouterR

eth0


R2 192168221

Internet

R3 192168331

eth1

eth2

DS 192168222

WS 192168332
























052

4745

296

5

280

24

063

435

059

58

056

0366

667


ProgramsApache

0

05

1

15

2

25

3

35

Aver

age t

ime d

elay

(ms)


656

8

079

69

074

565

075

12

071

915

2840482333



ProgramsApache

0

50

100

150

200

250

300Av

erag

e tim

e del

ay (m

s)












0

05

1

15

2

25

Aver

age t

ime d

elay

(Sec

)







01

02

03

04

05

06

07

08

09

1

Aver

age t

ime d

elay

(Sec





5

10

15

20

25

30

35

40

Aver

age t

ime d

elay

(ms)








ProgramsApache

0

20

40

60

80

100

120

140

Aver

age t

hrou

ghpu

t (KB

S)











ProgramsApache

0

200

400

600

800

1000

1200

1400

1600

1800

Aver

age t

hrou

ghpu

t (KB

S)






























10 Conclusion







Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation


















































4 Related Work



































DS


Inq = RejectElse



BA








1- Join_Request

6- Join_Response

Keys PKWSRKWS PKBA


3- Response_Enquiry

4- Join

5- Join_Reply










DS













6 Implementation










CKeys PKDS PKBA

DS

Keys PKDSRKDS PKBA


1- DNS_Query

2- DNS_Reply




























C 1921681120

ATT 1921681121

Switch

RouterR

eth0


R2 192168221

Internet

R3 192168331

eth1

eth2

DS 192168222

WS 192168332
























052

4745

296

5

280

24

063

435

059

58

056

0366

667


ProgramsApache

0

05

1

15

2

25

3

35

Aver

age t

ime d

elay

(ms)


656

8

079

69

074

565

075

12

071

915

2840482333



ProgramsApache

0

50

100

150

200

250

300Av

erag

e tim

e del

ay (m

s)












0

05

1

15

2

25

Aver

age t

ime d

elay

(Sec

)







01

02

03

04

05

06

07

08

09

1

Aver

age t

ime d

elay

(Sec





5

10

15

20

25

30

35

40

Aver

age t

ime d

elay

(ms)








ProgramsApache

0

20

40

60

80

100

120

140

Aver

age t

hrou

ghpu

t (KB

S)











ProgramsApache

0

200

400

600

800

1000

1200

1400

1600

1800

Aver

age t

hrou

ghpu

t (KB

S)






























10 Conclusion







Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation







































DS


Inq = RejectElse



BA








1- Join_Request

6- Join_Response

Keys PKWSRKWS PKBA


3- Response_Enquiry

4- Join

5- Join_Reply










DS













6 Implementation










CKeys PKDS PKBA

DS

Keys PKDSRKDS PKBA


1- DNS_Query

2- DNS_Reply




























C 1921681120

ATT 1921681121

Switch

RouterR

eth0


R2 192168221

Internet

R3 192168331

eth1

eth2

DS 192168222

WS 192168332
























052

4745

296

5

280

24

063

435

059

58

056

0366

667


ProgramsApache

0

05

1

15

2

25

3

35

Aver

age t

ime d

elay

(ms)


656

8

079

69

074

565

075

12

071

915

2840482333



ProgramsApache

0

50

100

150

200

250

300Av

erag

e tim

e del

ay (m

s)












0

05

1

15

2

25

Aver

age t

ime d

elay

(Sec

)







01

02

03

04

05

06

07

08

09

1

Aver

age t

ime d

elay

(Sec





5

10

15

20

25

30

35

40

Aver

age t

ime d

elay

(ms)








ProgramsApache

0

20

40

60

80

100

120

140

Aver

age t

hrou

ghpu

t (KB

S)











ProgramsApache

0

200

400

600

800

1000

1200

1400

1600

1800

Aver

age t

hrou

ghpu

t (KB

S)






























10 Conclusion







Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation













DS













6 Implementation










CKeys PKDS PKBA

DS

Keys PKDSRKDS PKBA


1- DNS_Query

2- DNS_Reply




























C 1921681120

ATT 1921681121

Switch

RouterR

eth0


R2 192168221

Internet

R3 192168331

eth1

eth2

DS 192168222

WS 192168332
























052

4745

296

5

280

24

063

435

059

58

056

0366

667


ProgramsApache

0

05

1

15

2

25

3

35

Aver

age t

ime d

elay

(ms)


656

8

079

69

074

565

075

12

071

915

2840482333



ProgramsApache

0

50

100

150

200

250

300Av

erag

e tim

e del

ay (m

s)












0

05

1

15

2

25

Aver

age t

ime d

elay

(Sec

)







01

02

03

04

05

06

07

08

09

1

Aver

age t

ime d

elay

(Sec





5

10

15

20

25

30

35

40

Aver

age t

ime d

elay

(ms)








ProgramsApache

0

20

40

60

80

100

120

140

Aver

age t

hrou

ghpu

t (KB

S)











ProgramsApache

0

200

400

600

800

1000

1200

1400

1600

1800

Aver

age t

hrou

ghpu

t (KB

S)






























10 Conclusion







Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation












CKeys PKDS PKBA

DS

Keys PKDSRKDS PKBA


1- DNS_Query

2- DNS_Reply




























C 1921681120

ATT 1921681121

Switch

RouterR

eth0


R2 192168221

Internet

R3 192168331

eth1

eth2

DS 192168222

WS 192168332
























052

4745

296

5

280

24

063

435

059

58

056

0366

667


ProgramsApache

0

05

1

15

2

25

3

35

Aver

age t

ime d

elay

(ms)


656

8

079

69

074

565

075

12

071

915

2840482333



ProgramsApache

0

50

100

150

200

250

300Av

erag

e tim

e del

ay (m

s)












0

05

1

15

2

25

Aver

age t

ime d

elay

(Sec

)







01

02

03

04

05

06

07

08

09

1

Aver

age t

ime d

elay

(Sec





5

10

15

20

25

30

35

40

Aver

age t

ime d

elay

(ms)








ProgramsApache

0

20

40

60

80

100

120

140

Aver

age t

hrou

ghpu

t (KB

S)











ProgramsApache

0

200

400

600

800

1000

1200

1400

1600

1800

Aver

age t

hrou

ghpu

t (KB

S)






























10 Conclusion







Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation



















C 1921681120

ATT 1921681121

Switch

RouterR

eth0


R2 192168221

Internet

R3 192168331

eth1

eth2

DS 192168222

WS 192168332
























052

4745

296

5

280

24

063

435

059

58

056

0366

667


ProgramsApache

0

05

1

15

2

25

3

35

Aver

age t

ime d

elay

(ms)


656

8

079

69

074

565

075

12

071

915

2840482333



ProgramsApache

0

50

100

150

200

250

300Av

erag

e tim

e del

ay (m

s)












0

05

1

15

2

25

Aver

age t

ime d

elay

(Sec

)







01

02

03

04

05

06

07

08

09

1

Aver

age t

ime d

elay

(Sec





5

10

15

20

25

30

35

40

Aver

age t

ime d

elay

(ms)








ProgramsApache

0

20

40

60

80

100

120

140

Aver

age t

hrou

ghpu

t (KB

S)











ProgramsApache

0

200

400

600

800

1000

1200

1400

1600

1800

Aver

age t

hrou

ghpu

t (KB

S)






























10 Conclusion







Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation


















052

4745

296

5

280

24

063

435

059

58

056

0366

667


ProgramsApache

0

05

1

15

2

25

3

35

Aver

age t

ime d

elay

(ms)


656

8

079

69

074

565

075

12

071

915

2840482333



ProgramsApache

0

50

100

150

200

250

300Av

erag

e tim

e del

ay (m

s)












0

05

1

15

2

25

Aver

age t

ime d

elay

(Sec

)







01

02

03

04

05

06

07

08

09

1

Aver

age t

ime d

elay

(Sec





5

10

15

20

25

30

35

40

Aver

age t

ime d

elay

(ms)








ProgramsApache

0

20

40

60

80

100

120

140

Aver

age t

hrou

ghpu

t (KB

S)











ProgramsApache

0

200

400

600

800

1000

1200

1400

1600

1800

Aver

age t

hrou

ghpu

t (KB

S)






























10 Conclusion







Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation















0

05

1

15

2

25

Aver

age t

ime d

elay

(Sec

)







01

02

03

04

05

06

07

08

09

1

Aver

age t

ime d

elay

(Sec





5

10

15

20

25

30

35

40

Aver

age t

ime d

elay

(ms)








ProgramsApache

0

20

40

60

80

100

120

140

Aver

age t

hrou

ghpu

t (KB

S)











ProgramsApache

0

200

400

600

800

1000

1200

1400

1600

1800

Aver

age t

hrou

ghpu

t (KB

S)






























10 Conclusion







Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











ProgramsApache

0

20

40

60

80

100

120

140

Aver

age t

hrou

ghpu

t (KB

S)











ProgramsApache

0

200

400

600

800

1000

1200

1400

1600

1800

Aver

age t

hrou

ghpu

t (KB

S)






























10 Conclusion







Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation
































10 Conclusion







Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation














Notations

Parameter


Function



119884



Acknowledgments


References









































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation



































RoboticsJournal of





Journal of



RotatingMachinery



Journal of

Volume 201


VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation









Enc-DNS-HTTP: Utilising DNS Infrastructure to Secure Web...

Documents

Transcript of Enc-DNS-HTTP: Utilising DNS Infrastructure to Secure Web...