Analyzing Cryptographic Protocols
Protocols chosen: Wireguard Protocol, OAuth2
- Identifing the functional purpose of each protocol.
Proto 1: Wireguard Protocol
WireGuard is a communication protocol which is a free and open-source software application. It is a layer 3 protocol and establishes secure point-to-point connections in routed or bridged configurations by implementing a virtual private network. WireGuard provides a VPN that is both straightforward and exceptionally compelling. It runs inside the Linux kernel as a module and targets better performance and more power saving than the popular VPN technologies like IPsec and OpenVPN tunneling protocols These technologies are often intricate to set up, disconnect easily (in the absence of further configuration), take considerable time to reconnect, may use outdated ciphers, and have relatively massive code bases which makes it difficult to detect bugs present. Wireguard overcomes these disadvantages. However, research on wireguard is not yet complete.
“It uses a single round trip key exchange, based on NoiseIK, and handles all session creation transparently to the user using a novel timer state machine mechanism. Short pre-shared static keys—Curve25519 points—are used for mutual authentication in the style of OpenSSH. The protocol provides strong perfect forward secrecy in addition to a high degree of identity hiding. Transport speed is accomplished using ChaCha20Poly1305 authenticated-encryption for encapsulation of packets in UDP. An improved take on IP-binding cookies is used for mitigating denial of service attacks, improving greatly on IKEv2 and DTLS’s cookie mechanisms to add encryption and authentication”
Proto 2: OAuth2.0
OAuth2.0 is an authorization protocol, replacing OAuth1.0. OAuth2.0 enables third party applications to access the protected resources of a resource owner hosted by HTTP server(in a client-server application). The access is requested by the resource owner in that HTTP service or is requested by the third party application itself. Instead of sharing the credentials of resource owner to the client or third party applications (which could allow unrestricted access to all resources without any provision to revoke access of a particular third party application without changing credentials), OAuth adds an authorization layer between the client and resource owner. This layer provides an access token to the client with specific scopes, lifetime and access attributes.
Note: The server and HTTP service will be used interchangeably in this document.
- Wireguard is a Communication Protocol and OAuth2.0 is an authorization protocol.
- Wireguard establishes a point to point connection by implementing a virtual private network, whereas OAuth2.0 enables third party applications to access the protected resources of a resource owner hosted by HTTP server.
- OAuth2.0 adds an authorization layer between client and resource owner. Wireguard does not have any layers, rather only a virtual interface
- Wireguard uses a novel timer state machine mechanism and exchanging public keys for handling sessions. OAuth2.0 uses an access token to the client with specific scopes, lifetime and access attributes
- Both the protocols involve a client-server connection setup.
- Security model of each protocol
Proto 1 - Wireguard: .
- An adversary has the capability to act like a man in the middle and replace source IP addresses. If an adversary is active, it can redirect the packets.
- An adversary has the ability to know which peer has sent a handshake. This is because Wireguard requires that the first message received by the receiver should authenticate the sender. The handshake encrypts the sender’s public key using the receiver’s public key and a compromise of the receiver’s private key(An attacker could replay initial handshake messages to trick the receiver into regenerating its ephemeral key,which will make the session of legitimate initiator as invalid) and previous logs of handshakes would grant the attacker to know the sender.
- To determine the authenticity of a handshake message, a Curve25519 multiplication must be computed, which means an adversary can perform denial-of-service attack as this operation is CPU intensive.
- Adversaries may be recording encrypted traffic on a long term basis, hoping that they might be able to break Curve25519 and decrypt past traffic.
Trust Model :
- Even if the adversary gets hold of the IP packets, these packets, however, remain indecipherable by the attacker, by virtue of WireGuard's usual authenticated encryption. A 12-byte TAI64N timestamp is included, encrypted and authenticated, in the first message. The responder keeps track of the greatest timestamp received per peer and discards packets containing timestamps less than or equal to it. Along with this, wireguard has forward secrecy of data packets.
- It is possible for the endpoint address to be updated and for the man in the middle to relay packets after man in the middle position is gone.
- Wireguard has rotating or regenerating keys which makes it difficult for adversary to identify receiver’s private key as a post compromise security.
- If the receiver is underload, then instead of computing the Curve25519 multiplication, it can send a cookie to the initiator. The initiator has to include that cookie in his next message so that responder can authenticate it.
- By the time adversaries are able to break Curve25519, the pre-shared symmetric key has been long forgotten. Also, it is assumed that if the pre-shared symmetric key is compromised, the Curve25519 keys still provide more than sufficient protection.
Proto 2 - OAuth2:
Trust Model or Assumptions:
- The Authorization Code (as described in next Q3), needs to be short-lived to reduce the threats as they can be exposed on browser queries. Also, instead of directly passing tokens, codes are exchanged for tokens to add one more step of verification and exchange tokens on a more secure connection between client and authorization server.
- The access tokens should have large string length and also have scopes within them to enable the clients to access only certain resources. Also, the lifetime of such tokens should be kept shorter. The short lifespan of an access token, in combination with the usage of refresh tokens, enables the possibility of passive revocation of access authorization on the expiry of the current access token.
- A refresh token is used by the client to obtain a new access token. Thus, in a way refresh token must be passed to Authorization Server to obtain a new access token and it also serves a purpose of authenticating the client at Authorization server.
- A secure Transport Layer Protocol must be used by the client to communicate with the Authorization Server or the Resource Server.
- The redirect_uri used by the client in the authorization and token requests must be used by authorization server to verify the client against the client id.
- The server hosts the resources of the resource owner to which the client can have a limited and restricted access. Thus, the server is assumed to behave in the way specified. It verifies the tokens and according to the scope(if present) allows access to the resource for the time till when the token is valid.
Also, we assume that the resource owners have strong passwords and brute force password guessing doesn't work, as such an attack exploits the vulnerability of any protocol.
Adversaries and their capabilities - Threat Model:
It is assumed that:
- The attacker has full access to the network between the client and authorization servers and the client and the resource server, respectively. The attacker may eavesdrop on any communications between those parties. He is not assumed to have access to communication between the authorization server and resource server.
- An attacker has unlimited resources to mount an attack.
- Two of the three parties involved in the OAuth protocol may collude to mount an attack against the 3rd party. For example, the client and authorization server may be under control of an attacker and collude to trick a user to gain access to resources.
- The ultimate threat from an adversary is to steal or modify any of the secret information which can be done in any manner: either by getting that information from one of the three parties or sniffing/modifying the network HTTP Traffic.
Maintaining the properties:
- For all the threats where an adversary catches hold of the tokens, authorization code or client secret, those particular tokens or codes are revoked and they should have limited scopes. Also, standard web server protection measures must be used.
- If a malicious client obtains existing authorization by fraud, this could have happened if the authorization server would want to automatically process the request of a client to whom the resource owner would have already granted access. This can be mitigated by limiting the scope of the tokens obtained by automated approval and also client must be validated against pre-registered redirect uri. Thus the authorization server must not authorize until and unless the client identifier and registered uri cant be verified.
- The tokens, codes and client credentials(client_id and secret) can be protected by communicating over TLS and also use HMAC for encrypting. Also, the Authorization server must have protection against SQL injections to protect client credentials.
- In WireGuard, the clients are acting on their behalf as it is the data within the network which needs protection. While in OAuth2, the clients are verified and authorized against their identity as well as consent and credentials of the actual resource owner(whose data needs protection).
- Cryptographic properties of Wireguard are similarly defined for anyone implementing the wireguard. OAuth2 leaves the choice on the implementation for cryptographic properties.
- Both protocols assume that the adversaries can intercept the network traffic and have the ability to modify the messages or requests.
- The authentication of the sender is verified in both the protocols first before data is transferred.
- Working of both the protocols
Proto 1: Wireguard Protocol
WireGuard utilizes the following:.
- Curve25519 for key exchange
- ChaCha20 for encryption
- Poly1305 for data authentication
- SipHash for hashtable keys
- BLAKE2s for hashing
- UDP-based only.
- Wireguard uses UDP to transfer the packets, typically 51820/UDP if no port is specified.
- A wireguard server configuration is having a single entry point for one interface and multiple peers are associated with this interface.
- Roadwarrior devices (clients) have one interface entry and one peer associated(server).
- Cryptokey Routing is utilized for WireGuard encryption. The mechanism works by associating public encryption keys with a list of allowed VPN tunnel IP addresses.
- Interface has a private key and UDP port on which it listens along with a list of peers. Each of the peers has a short and simple public key, used in authenticating it with other peers. These public keys may be distributed for use in configuration files in a number of ways, similar to transmission of SSH public keys. Each peer also has its own private key to authenticate the packet encrypted using its public key.
- Traffic routing via allowed IPs takes place as follows-
- Wildcard 0.0.0.0/0 : If the allowed IP is 0.0.0.0/0, it automatically encrypts any packet and send it through the VPN tunnel
- For other IPs, the traffic is allowed through the tunnel if it occurs in the list of allowed IPs.
- When sending packets, the list of allowed IPs behaves like a routing table, and when receiving packets, the list of allowed IPs behaves as an access control list.
- Data Encryption,decryption and working:
Before sending encrypted data packets, 1-RTT key exchange handshake takes place. This means a sender sends a message to the receiver and receiver send the reply to the sender. After this connection only exchanging of encrypted messages using a shared pair of symmetric keys takes place.
- For example, a server computer might have this configuration:
Pictures are taken from 
Routing table of the interface looks like the following:
“A packet is locally generated (or forwarded) and is ready to be transmitted on the outgoing interface wg0:
- The plaintext packet reaches the WireGuard interface, wg0.
- The destination IP address of the packet, 192.168.87.21 is inspected anndmatches the peer TrMv...WXX0. If there is no match the packet is dropped.
- The symmetric sending encryption key and nonce counter of the secure session associated with peer TrMv...WXX0 are used to encrypt the plaintext packet using ChaCha20Poly1305.
- A header containing various fields is prepended to the now encrypted packet.
- This header and encrypted packet, together, are sent as a UDP packet to the Internet UDP/IP endpoint associated with peer TrMv...WXX0, resulting in an outer UDP/IP packet containing as its payload a header and encrypted inner-packet. The peer’s endpoint is either pre-configured, or it is learned from the outer external source IP header field of the most recently correctly-authenticated packet received.
A UDP/IP packet reaches UDP port 41414 of the host, which is the listening UDP port of interface wg0:
- A UDP/IP packet containing a particular header and an encrypted payload is received on the correct port (in this particular case, port 41414).
- Using the header, WireGuard determines that it is associated with peer TrMv...WXX0’s secure session, checks the validity of the message counter, and attempts to authenticate and decrypt it using the secure session’s receiving symmetric key. If it cannot determine a peer or if authentication fails, the packet is dropped.
- Since the packet has been authenticated correctly, the source IP of the outer UDP/IP packet is used to update the endpoint for peer TrMv...WXX0.
- Once the packet payload is decrypted, the interface has a plaintext packet. If this is not an IP packet, it is dropped. Otherwise, WireGuard checks to see if the source IP address of the plaintext inner-packet routes correspondingly in the cryptokey routing table. For example, if the source IP of the decrypted plaintext packet is 192.168.31.28, the packet correspondingly routes. But if the source IP is 10.192.122.3, the packet does not route correspondingly for this peer, and is dropped.
- If the plaintext packet has not been dropped, it is inserted into the receive queue of the wg0 interface.”
- And a client computer might have this simpler configuration:
Pictures are taken from 
PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
ListenPort = 21841
PublicKey = kfkrF4fj5jy6i9ugFHQF5thi84ugtkkiFg5kjWjiiii0+efjEJ3jT=
Endpoint = 188.8.131.52:51820
AllowedIPs = 0.0.0.0/0
- In the client configuration, when the network interface wants to send a packet to its single peer (the server), it will encrypt packets for the single peer with any destination IP address (since 0.0.0.0/0 is a wildcard). For example, if the network interface is asked to send a packet with any destination IP, it will encrypt it using the public key of the single peer kfkrF4fj5jy6..., and then send it to the single peer's most recent Internet endpoint.
- The server which is the single peer, will be able to send packets to the network interface with any source IP (since 0.0.0.0/0 is a wildcard). For example, when a packet is received from peer kfkrF..., if it decrypts and authenticates correctly, with any source IP, then it's allowed onto the interface; otherwise it's dropped. 
Proto 2: OAuth2
Starting with an abstract flow diagram of the OAuth2 as adapted from the specification document :
Client: A Relying Party or a third party application requesting access to Protected Resources of Resource Owner.
Resource Owner: An entity which owns a resource on the Resource Server and can be using some user-agent to interact with Authorization Server(like a browser).
Resource Server: A server hosting Protected resources of resource owner.
The abstract flow is as follows:
- Client sends authorization request to the Resource Owner. This request can be made via the Authorization server as well.
- The Resource Owner sends the Authorization Grant, which represents the credentials required to authenticate with the Authorization Server. The Authorization Grant can be one of the four or a custom grant type and accordingly the credentials are used. We will discuss the Authorization Code Grant/Flow, as it is widely used.
- The client requests for an access token from the Authorization server, which authenticates the Resource Owner through the credentials inherent in Authorization Grant. This also means that the Resource Owner has consented the client to access the resources.
- The Authorization server returns a token which carries scope if the grant had scope values and also the token is short lived.
- The client uses the token within its validity period to access the resources from the Resource Server.
- The token is verified by the Resource Server against the scope, if available and returns the resource to the client.
Generally, the access tokens are of type Bearer. This implies that the Authorization field in the last request to Resource Server is of the form: “Bearer Access Token”. An access token can be JSON Web Token (JWT).
The AS provides authorization and token endpoints where the client makes requests for authorization and token generation respectively. Generally, the client using the services of the resource server would have registered its client_id(client identifier) and client_secret with AS. However the registration process as well creation process is out of the scope of OAuth2. Best practices use clinet_secret as well.
Let us use the scenario of Importing a document(Protected Resource) from Google Drive ( a service or Resource Server, RS). The client, for example, is Moodle, where a Resource Owner(RO), here a student, wants to authorize the Moodle to access Google drive. The Authorization Server(AS) here is Google. This example will deviate a bit from the abstract flow in a way because it uses a specific grant type: Authorization Code flow which is widely used in many web applications. The flow as adopted from  can be seen below:
- The student or RO is using an agent, web browser here. When the student clicks on the Google Drive option on Moodle, a redirect URI is sent in the request through the web browser to the AS (here Google) along with the identifier of the Client (Moodle) which is client_id.
- The AS authenticates the student (RO) and also asks whether the student wants the client app to access the requested resources. Let us assume that the student consented to give access. The AS sends the Authorization “Code” back to the browser. The browser sends the code to the redirect URI, which client had sent in the request body.
- The Moodle now sends a request to Google Authorization server(at token endpoint) with the Authorization Code received on behalf of the student. It queries for a token in the request it sends to AS. The client also sends the redirection UR and the client_id it had sent before for verification.
- The AS authenticates the Moodle(or client), validates the authorization code and client_id. If everything is correct, it sends the Access token back to Moddle.
- Moodle uses this access token to access the google drive end points and request the protected resources of the student.
- Finally, the protected resources are seen on the Moodle.
Note: The Google authorize endpoint uses a scope with values some default values like-profile, openid, email and other specific scopes which are pertaining to API requested by client.
- The requests have "application/x-www-form-urlencoded" format. The fields which are mandatory in the Authorization request are request_type, redirect_uri, client_id and scope. (Example: we can see this fields while accessing google APIs from third party applications)
- Once the code is received the access token request will include the fields code, redircet_uri and client_id as necessary fields.
- All the requests and responses are required to use Transport Security Layer(TLS) or any better encrypted transport layer which is compatible to encrypt the requests. The client especially uses it for the redirection uri as well while making requests as the credentials and code transmitted are in clear-text. The same is true for AS as well.
- OpenID Connect (OIDC) with OAuth2 is widely used today as OIDC provides a layer of Authentication over OAuth2. The AS can also function as Identity Provider and even the Client service can have its own Identity Provider. But in the above example, Google AS functioned as Identity Provider for Moodle(Relying Party). The AS provides ID Token as well apart from the Access Token. The ID Token has information about the student.
- The client-server interactions are totally different in both the protocols as they both serve different purposes. The HTTP requests and responses exchanged in OAuth2 can very well be within the WireGuard VPN tunnels.
- In Wireguard, the client and server just need to pass on encrypted messages using peer’s public key over UDP, while OAuth2 requires sending of HTTP requests over TLS (no matter whether it uses UDP or TCP).
- The Wireguard uses encryption and decryption and Peer Addresses for authentication to authenticate and verify whether messages were sent from a Peer in VPN, while OAuth2 uses Codes (or Authorization Grant in a generic setting) and Tokens to authenticate and verify whether the requests are genuine or not, which may or may not be encrypted. The Tokens can be signed.
- The server in WireGuard only has all the `public` keys of all the clients or peers. While in OAuth2, the Authorization Server needs to store the `public` client_id as well as `private` client_secret of the client (as generally both are used and registered).
- The client in OAuth2 needs to interact with at least two entities to get access to a resource while WireGuard requires only one message transfer from the client (to server in RoadWarrior or peer in Peer-to-Peer ).
- Authentication and verification are necessary steps in both the protocols to know the identity of the client (in Oauth2, during the interaction with AS).
- Keys generation, distribution and storage
Proto 1: Keys in Wireguard Protocol
- Key Generation:
WireGuard encrypts the connection using a pair of cryptographic keys. For a secure communication both ways, both parties should have their own private and public keys and then exchange public keys.
- DH-Generate() : Generates a random Curve25519 private key and derives its corresponding public key, returning a pair of 32 bytes values, (private, public).
- “The X25519 function can be used in an Elliptic Curve Diffie-Hellman (ECDH) protocol as follows:
Alice generates 32 random bytes in a to a and transmits K_A = X25519(a, 9) to Bob, where 9 is the u-coordinate of the base point and is encoded as a byte with value 9, followed by 31 zero bytes.
Bob similarly generates 32 random bytes in b to b, computes K_B = X25519(b, 9), and transmits it to Alice.
Using their generated values and the received input, Alice computes X25519(a, K_B) and Bob computes X25519(b, K_A). Both now share K = X25519(a, X25519(b, 9)) = X25519(b, X25519(a, 9)) as a shared secret.
Both MAY check, without leaking extra information about the value of K, whether K is the all-zero value and abort if so.
Alice and Bob can then use a key-derivation function that includes K, K_A, and K_B to derive a symmetric key.”
- To create a private key run:
$ (umask 0077; wg genkey peer_A.key)
To create a public key:
$ wg pubkey peer_A.key peer_A.pub
- Key distribution:
Wireguard does not have the scope for key generation and pushing configurations. These issues are taken care of by other layers such that any key distribution solution can be used by Wireguard. In contrast, it is similar to the model of SSH and Mosh in a way that both parties (peer-peer, server-peer) have each other's public keys, and then they exchange packets through the interface. Its keys are 32 bit long and can be easily represented in Base64 encoding in 44 characters which provides ease in transferring keys through multiple mediums. It utilizes Curve25519 for key exchange.
- Key Storage:
The storage of keys in Wireguard is specific to each system or peer in the VPN. Wireguard generates the keypair, that is its public and private part and stores it within VyOS( an open source network operating system based on Debian GNU/Linux).
Keys are usually stored in /etc/wireguard folder. 
Proto 2: Token Generation, Distribution and Storage in OAuth2:
- Access Tokens:
There are two types of tokens that can be used: MAC tokens or Bearer Tokens, where the latter one requires a strict usage of TLS communication to and fro for the client. Even for the key distribution step for MAC tokens, TLS is strictly required.
Bearer Tokens are popularly and widely used tokens and thus have been explained here. As defined in , Bearer Token is:
“A security token with the property that any party in possession of
the token (a "bearer") can use the token in any way that any other
party in possession of it can. Using a bearer token does not
require a bearer to prove possession of cryptographic key material
According to , the access tokens are identifiers that can be used to retrieve the authorization information of the client to access protected resources or the tokens can self-contain the authorization data in a verifiable manner. If identifier tokens are used, then the Resource Server needs to communicate with the AS and know what are the permissions associated with the token. The resource server reaches out at the /introspection endpoint of the AS.
The self-contained tokens are widely used, specifically the JSON Web Tokens (JWTs) which are self-contained tokens that are signed.
- Token Generation and Verification:
JWTs have Json serialized fields including all the data and are signed with a key known to the Servers. The Authorization Server has a JWT_KEY which is used to sign the JSON data. JSON data includes the data required to authorize the client to access resources. It generally includes (‘sub’, ‘iss’, ‘cid’, ‘exp’, ‘scope’). It can have extra fields based on what resource servers require(like user or resource owner details).
‘sub’ : user id
‘iss’ : Issue token endpoint
‘cid’ : client_id
‘exp’ : expiry of token
‘scope’ : scopes (like read write some particular APIs)
Finally using the JWT_KEY the data is signed into JWT which is of the following form:
On decoding this JWT, the following is retrieved:
First component (the blue one) which is header:
Second component(green one) which is data:
"scope": "read write"
Third component is used to verify the signature. This is done as follows for the given example with signing algorithm as HS256 (HMAC with SHA-256):
HS256(base64UrlEncode(header) + ‘.’ + base64UrlEncode(data), JWT_KEY)
The Single Sign on Authorization Servers provide RS256 (RSA Signature with SHA-256 asymmetric signing algorithm) as well.
For Asymmetric Signing Algorithm, to decode the JWT, resource owner needs to obtain the public key from the AS. The public key is made available at the JWK Set endpoint of the AS, according to the JSON Web Key Specification Document . This has the JWK that the resource server should use to validate the JWT and know who was the issuer and whether it was modified or not.
Generally web applications use Authorization Servers(AS) which provide the resource servers with a secret key (same as what AS will keep for signing tokens in symmetric signing like HS256) or with a public key (while private key is used by AS to sign tokens in asymmetric signing like RS256).
- Token Distribution:
The Authorization Server sends the token as part of the payload of the HTTP response over TLS to the client and also include “Token_type”: “Bearer”.
These Bearer JWTs are sent as part of the Authorization field of the HTTP Header in the request made by the client to the Resource Server.
- Token Storage:
Now, coming to how tokens are stored by the client: the tokens can be used till they expire and a new access token is requested based on the refresh token (if AS provided it). The tokens can be stored in the database. If the tokens are to be used only while the client interacts with a resource server through a HTTP session, then tokens can be stored in the middleware of such sessions. In both the scenarios, it is better to hash or encrypt them and store.
Note: If the keys are compromised by the resource server, the resource server needs to be redeployed with new keys. The AS is responsible for rotating the keys when such scenarios occur. Generally the JWT Keys are generated by the AS and are distributed to the resource server. Resource server needs to securely save it and keep on changing the keys. This is implementation detail for Authorization Server and Resource Server.
- Wireguard requires keys for encrypting and decrypting the message communication while OAuth2 requires keys for signing and verifying the JSON Web Tokens that are passed between Authorization Server, Client and Resource Server.
- Each client and the server generate the key pairs and then transmit the public keys to other peers in Wireguard. While in OAuth2, the tokens and even the key used to sign that key are generated by the Authorization Server and they need to be securely distributed.
- The storage of keys in Wireguard is specific to each system or peer in the VPN. While in OAuth2, the tokens are stored securely by the applications either in database or middleware of the client-server session.
- Keys in both the protocols are distributed whenever they are generated. However, the tokens in OAuth2 are distributed to clients whenever they expire.
- Well-known vulnerabilities and their solutions
Proto 1: Wireguard Protocol
The following are the vulnerabilities of Wireguard protocol and the solution to overcome those vulnerabilities.
- Problem 1: By default, Wireguard saves connected user IP addresses on the server and stores them for an indefinite amount of time or until the server is rebooted. This makes the WireGuard irreconcilable with no-logs VPN (virtual private network provider does not collect, or log any information transmitted through the network). This leads to a compromise on privacy. 
- The first interface assigns a local IP address to the users which connect to the server, thus making all users get the same IP address. Once this VPN tunnel is established, the second network interface assigns a unique IP address for each tunnel using dynamic NAT system. This allows to establish a secure VPN server without storing any data which can be identified on the server. Once the session deactivates, the dynamic local IP addresses are gone. This approach was taken by NordVPN double NAT system with WireGuard, known as NordLynx.
- Configure servers to erase logs when session deactivates. For this, user information is not stored forever in the VPN server’s memory, instead for a short span. If the users are not making any connection to the server for 3 minutes, the users are deleted. This approach was taken by Mullvad and OVPN. Thus, no user logs are stored.
- Problem 2- Dynamic IP addresses are not assigned by Wiredguard. It only assigns static IPs. This is harmful because if a user experiences WebRTC leaks, that static internal IP address could leak externally.
Apart from this, application on your device can track your internal IP applications, this can be very dangerous especially if the software is malicious and may leak information.
- Disable or block WebRTC
- Use a secure and private browser to limit exposure of data.
- Regenerate keys and rotate IP addresses.
Both OVPN and Mullvad have implemented these solutions.
The utility of the protocol is not affected significantly because of these solutions.
Proto 2: OAuth2.0 .
Both these attacks can be applied to Authorization Code flow as described in the Moodle example:
- HTTP 307 URL redirection attack: In this attack, the attacker (running a malicious client) learns the user’s (or resource owner’s) credentials when the user logs in at an AS that uses the wrong HTTP redirection status code. It is assumed that for this attack to occur, the resource owner is authorizing a malicious client to access the protected resources and the client is collecting all the data that it receives. Also, the AS immediately redirects the browser or user agent of the resource provider via 307 HTTP status code instead of 302 status code(which is recommended in ).
What is wrong with status code 307: The HTTP standard defines that only status response code 303 drops the original HTTP POST request’s headers which had user’s credentials and form data. For status code 302, the decision is left to the browser and browser will drop the form data in practice while for status code 307, the form data is included in the response sent back.
Solution: This should not be left to implementation and OAuth should require using status code 303 whenever the AS immediately redirects to the redirect_uri provided by the client.
- Authorization Server Mix-up: The attacker confuses a client regarding which AS the user (or the resource owner) chose at the beginning of the authorization/login process in order to acquire authorization code or access tokens to impersonate the resource owner or use their data.
The attacker manipulates the first request of the user such that the client thinks that the user wants to use an identity managed by AS of the attacker while the user instead wishes to use the identity managed by an honest AS. This is done by interception of the HTTP request made through the browser or user agent. As a result, the client sends the authorization code or the access token (depending on the OAuth mode) issued by the actual AS to the attacker, who then can use these values to access the user’s protected resources at the Resource Server. This is done by the attacker by again modifying the redirect_uri in the request. This could occur even if the communication was over HTTPS.
Solution: There should be a mechanism for the client to check from where the redirect was initiated and verify the identity of AS.
Again, both of these solutions do not affect the utility of the protocol
- In the vulnerabilities of OAuth2, the protocol does not require using status code 303 whenever the authorization server immediately redirects to the redirect url provided by the client. Also, there is no mechanism for the client to check from where the redirect was initiated and verify the identity of AS.
In vulnerabilities of Wireguard, Wireguard saves connected user IP addresses on the server and stores them for an indefinite amount of time or until the server is rebooted. Also, Dynamic IP addresses are not assigned by Wireguard. It only assigns static IPs.
- The difference between both protocols is that Wireguard’s vulnerabilities lead to a compromise on the user’s IP addresses whereas OAuth2’s vulnerabilities lead to a compromise on users’ credentials and their data.
- In both the protocols, privacy of the users is on stake.
- In OAuth2, the attacker manipulates the user's request to make the client believe that client wants to use an identity managed by the attacker’s AS by manipulating the user’s request. This seems like a spoofing and man in the middle attack. Wireguard protocol also involves an attack by man in the middle which can replace the source IP address.
- B. Preneel, F. ; Vercauteren, Applied Cryptography and Network Security. Springer. ISBN 978-3-319-93387-0. Archived from the original on 18 February 2019. Retrieved 25 June 2018.
- J. Salter, "WireGuard VPN review: A new type of VPN offers serious advantages". Ars Technica. Archived from the original on 20 September 2018.
- E. D Hardt. "RFC 6749 - The OAuth 2.0 Authorization Framework". Internet Engineering Task Force (IETF), 2012. [Online]. Available: https://tools.ietf.org/html/rfc6749.
- T. Lodderstedt, Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations". Internet Engineering Task Force (IETF). January 2013. [Online]. Available: https://tools.ietf.org/html/rfc6819
- En.wikipedia.org. 2020. Wireguard. [online] Available at: https://en.wikipedia.org/wiki/WireGuard [Accessed 9 September 2020].
- Donenfeld, Jason, "WireGuard: Next Generation Kernel Network Tunnel". 2017. 10.14722/ndss.2017.23160.
- Finjan Team, "What is WireGuard? A Closer Look at a New VPN Technology". June, 2018
- T. Sven. "WireGuard VPN: What You Need to Know". August, 2020.
- Daniel Fett, Ralf Küsters, and Guido Schmitz."A Comprehensive Formal Security Analysis of OAuth 2.0". InProceedings of the 2016. ACM SIGSAC Conference on Computer and Communications Security(CCS ’16). Association for Computing Machinery, New York, NY, USA,1204–1215. https://doi.org/10.1145/2976749.2978385
- T. Niedermeier, "WireGuard Basics - Thomas-Krenn-Wiki", Thomas-krenn.com. [Online]. Available: https://www.thomas-krenn.com/en/wiki/WireGuard_Basics.
- J. Donenfeld and P. Mello, "WireGuard in Launchpad", Launchpad. [Online]. Available: https://launchpad.net/wireguard-linux. [Accessed: 09- Sep- 2020].
- Wiki.archlinux.org. 2020. Wireguard - Archwiki. [online] Available at: https://wiki.archlinux.org/index.php/WireGuard#Key_generation [Accessed 9 September 2020].
- Donenfeld, Jason. (2017). WireGuard:Next Generation Kernel Network Tunnel. 10.14722/ndss.2017.23160.
- M. Jones, D. Hardt. "The OAuth 2.0 Authorization Framework: Bearer Token Usage". Internet Engineering Task Force (IETF). 2012. [Online]. Available: https://tools.ietf.org/html/rfc6750.
- M. Jones. "JSON Web Key (JWK)". Internet Engineering Task Force (IETF). 2015. [Online]. Available: https://tools.ietf.org/html/rfc7517.
- A. Langley, M. Hamburg and S. Turner. "Elliptic Curves for Security". Internet Engineering Task Force (IETF). January 2016. [Online]. Available: https://www.ietf.org/rfc/rfc7748.txt by on
- "WireGuard — VyOS 1.3.x (equuleus) documentation", Docs.vyos.io. [Online]. Available: https://docs.vyos.io/en/latest/vpn/wireguard.html. [Accessed: 09- Sep- 2020].
- "Self-Encoded Access Tokens - OAuth 2.0 Simplified", OAuth 2.0 Simplified. [Online]. Available: https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/. [Accessed: 09- Sep- 2020].