Protocol Encryption - Revision history

imported>LassiPulkkinen: Good edit otherwise, but there's no way the Encryption Response is sent encrypted; that would be and chicken and egg problem. Removing the sentence completely since it's already mentioned in the preceding paragraph. Also, slight wording and typo fixes.

2024-08-05T00:14:07Z

Good edit otherwise, but there's no way the Encryption Response is sent encrypted; that would be and chicken and egg problem. Removing the sentence completely since it's already mentioned in the preceding paragraph. Also, slight wording and typo fixes.

← Older revision		Revision as of 00:14, 5 August 2024
Line 49:		Line 49:
	== Symmetric Encryption ==		== Symmetric Encryption ==

	When it receives an Encryption Request from the server, the client will generate a random 16-byte (128-bit) shared secret, to be used with the AES/CFB8 stream ciphers. It then encrypts the shared secret and verify token with the server's public key (PKCS#1 v1.5 padded), ~~then~~ sends both to the server in an Encryption Response packet. Both byte arrays in the Encryption Response packet will be 128 bytes long because of the padding. This is the only time the client uses the server's public key.		When it receives an Encryption Request from the server, the client will generate a random 16-byte (128-bit) shared secret, to be used with the AES/CFB8 stream ciphers. It then encrypts the shared secret and verify token with the server's public key (PKCS#1 v1.5 padded), and sends both to the server in an Encryption Response packet. Both byte arrays in the Encryption Response packet will be 128 bytes long because of the padding. This is the only time the client uses the server's public key.

	[[File:Icon_exclaim.gif\|:!:]] In your crypto library, ensure that you set up your "feedback/segment size" to 8 bits or 1 byte, as indicated in the name AES/CFB'''8'''. Any other feedback size will result in encryption mismatch.		[[File:Icon_exclaim.gif\|:!:]] In your crypto library, ensure that you set up your "feedback/segment size" to 8 bits or 1 byte, as indicated in the name AES/CFB'''8'''. Any other feedback size will result in encryption mismatch.

	The server decrypts the shared secret and token using its private key, and checks if the token is the same. It then enables AES/CFB8 encryption and sends the Login Success packet encrypted. The server makes two ciphers, one for encryption and one for decryption, with the key and initial vector (IV) both set to ~~she~~ shared secret. The client does the same, setting up its own two ciphers identically. From this point forward, everything is encrypted, including the length field, packet ID, and data length (if compression is enabled).		The server decrypts the shared secret and token using its private key, and checks if the token is the same. It then enables AES/CFB8 encryption and sends the Login Success packet encrypted. The server makes two ciphers, one for encryption and one for decryption, with the key and initial vector (IV) both set to the shared secret. The client does the same, setting up its own two ciphers identically. From this point forward, everything is encrypted, including the length field, packet ID, and data length (if compression is enabled).

	~~The Login Success and Encryption Response packets are sent encrypted~~.

	[[File:Icon_exclaim.gif\|:!:]] Note that the AES cipher is updated continuously, not finished and restarted every packet.		[[File:Icon_exclaim.gif\|:!:]] Note that the AES cipher is updated continuously, not finished and restarted every packet.

imported>ZWORX52: /* Symmetric Encryption */ Clarify & reword for clarity, noting that both client and server have two ciphers: one for decryption, and one for encryption.

2024-08-04T17:22:44Z

Symmetric Encryption: Clarify & reword for clarity, noting that both client and server have two ciphers: one for decryption, and one for encryption.

← Older revision		Revision as of 17:22, 4 August 2024
Line 49:		Line 49:
	== Symmetric Encryption ==		== Symmetric Encryption ==

	~~On receipt of a~~ Encryption Request from the server, the client will generate a random 16-byte shared secret, to be used with the AES/CFB8 stream ~~cipher~~. It then encrypts it with the server's public key (PKCS#1 v1.5 padded)~~, and also encrypts the verify token received in the Encryption Request packet in the same way~~, then sends both to the server in a Encryption Response packet. Both byte arrays in the Encryption Response packet will be 128 bytes long because of the padding. This is the only time the client uses the server's public key.		When it receives an Encryption Request from the server, the client will generate a random 16-byte (128-bit) shared secret, to be used with the AES/CFB8 stream ciphers. It then encrypts the shared secret and verify token with the server's public key (PKCS#1 v1.5 padded), then sends both to the server in an Encryption Response packet. Both byte arrays in the Encryption Response packet will be 128 bytes long because of the padding. This is the only time the client uses the server's public key.

	[[File:Icon_exclaim.gif\|:!:]] In your crypto library, ensure that you set up your "feedback/segment size" to 8 bits or 1 byte, as indicated in the name AES/CFB'''8'''. Any other feedback size will result in encryption mismatch.		[[File:Icon_exclaim.gif\|:!:]] In your crypto library, ensure that you set up your "feedback/segment size" to 8 bits or 1 byte, as indicated in the name AES/CFB'''8'''. Any other feedback size will result in encryption mismatch.

	The server decrypts the shared secret and token using its private key, and checks if the token is the same. It then ~~sends a Login Success, and~~ enables AES/CFB8 encryption. ~~For~~ the ~~Initial Vector~~ (IV) ~~and AES setup,~~ both ~~sides use the~~ shared secret ~~as both the IV and~~ the ~~key. Similarly~~, ~~the client will also enable encryption upon sending Encryption Response~~. From this point forward, everything ~~is encrypted. Note: the entire packet~~ is encrypted, including the length ~~fields~~ and ~~the packet's~~ data.		The server decrypts the shared secret and token using its private key, and checks if the token is the same. It then enables AES/CFB8 encryption and sends the Login Success packet encrypted. The server makes two ciphers, one for encryption and one for decryption, with the key and initial vector (IV) both set to she shared secret. The client does the same, setting up its own two ciphers identically. From this point forward, everything is encrypted, including the length field, packet ID, and data length (if compression is enabled).

	The Login Success ~~packet is~~ sent encrypted.		The Login Success and Encryption Response packets are sent encrypted.

	[[File:Icon_exclaim.gif\|:!:]] Note that the AES cipher is updated continuously, not finished and restarted every packet.		[[File:Icon_exclaim.gif\|:!:]] Note that the AES cipher is updated continuously, not finished and restarted every packet.

imported>WinX64: As of 24w03a, encryption can be enabled with offline-mode

2024-06-04T13:38:05Z

As of 24w03a, encryption can be enabled with offline-mode

← Older revision		Revision as of 13:38, 4 June 2024
Line 1:		Line 1:
	~~As of~~ 12w17a~~, Minecraft uses encrypted connections~~ for online-mode servers.		Encrypted connection is a feature introduced in 12w17a for online-mode servers. As of 24w03a, it can also be used with offline-mode.

	== Overview ==		== Overview ==
Line 6:		Line 6:
	# '''C'''→'''S''': [[Protocol#Login Start\|Login Start]]		# '''C'''→'''S''': [[Protocol#Login Start\|Login Start]]
	# '''S'''→'''C''': [[Protocol#Encryption Request\|Encryption Request]]		# '''S'''→'''C''': [[Protocol#Encryption Request\|Encryption Request]]
	# ''Client authentication''		# ''Client authentication (if enabled)''
	# '''C'''→'''S''': [[Protocol#Encryption Response\|Encryption Response]]		# '''C'''→'''S''': [[Protocol#Encryption Response\|Encryption Response]]
	# ''Server authentication~~, both~~ enable encryption''		# ''Server authentication (if enabled)''
			# ''Both enable encryption''
	# '''S'''→'''C''': [[Protocol#Login Success\|Login Success]]		# '''S'''→'''C''': [[Protocol#Login Success\|Login Success]]

Line 60:		Line 61:
	== Authentication ==		== Authentication ==

	~~Both~~ server and client need to make a request to sessionserver.mojang.com ~~if the server is in online-mode~~.		If enabled during [[Protocol#Encryption Request\|Encryption Request]], both server and client need to make a request to sessionserver.mojang.com.

	=== Client ===		=== Client ===

imported>WithAnimeException: emphasize need for correct content-type; add extra possible error i got while writing a client; remove "HTTP/1.1" as server supports other http versions

2024-04-02T20:01:50Z

emphasize need for correct content-type; add extra possible error i got while writing a client; remove "HTTP/1.1" as server supports other http versions

← Older revision		Revision as of 20:01, 2 April 2024
Line 80:		Line 80:
	The resulting hash is then sent via an HTTP POST request to		The resulting hash is then sent via an HTTP POST request to
	<nowiki>https://sessionserver.mojang.com/session/minecraft/join</nowiki>		<nowiki>https://sessionserver.mojang.com/session/minecraft/join</nowiki>
	With the following sent as post data, Content-Type: application/json		With the following sent as post data. You ''must'' have the Content-Type header set to application/json or you will get a 415 Unsupported Media Type or 403 Forbidden response.
	<syntaxhighlight lang="javascript">		<syntaxhighlight lang="javascript">
	{		{
Line 91:		Line 91:
	The fields <accessToken> and the player's uuid were received by the client during [[Authentication#Authenticate\|authentication]].		The fields <accessToken> and the player's uuid were received by the client during [[Authentication#Authenticate\|authentication]].

	If everything goes well, the client will receive a "~~HTTP/1.1~~ 204 No Content" response.		If everything goes well, the client will receive a "204 No Content" response.

	The server will respond with "~~HTTP/1.1~~ 403 Forbidden" if the player's Xbox profile has multiplayer disabled, with the following response:		The server will respond with "403 Forbidden" if the player's Xbox profile has multiplayer disabled, with the following response:
	<syntaxhighlight lang="javascript">		<syntaxhighlight lang="javascript">
	{		{
Line 105:		Line 105:
	{		{
	"error": "UserBannedException",		"error": "UserBannedException",
			"path": "/session/minecraft/join"
			}
			</syntaxhighlight>

			If you forget to include a body with your request and just send an empty POST request, or if you use a malformed Content-Type header, you'll get this non-descriptive error:
			<syntaxhighlight lang="javascript">
			{
			"error": "Forbidden",
	"path": "/session/minecraft/join"		"path": "/session/minecraft/join"
	}		}

imported>Tinkererr: Fixed wrong direction of Encryption Response

2023-12-30T14:52:05Z

Fixed wrong direction of Encryption Response

← Older revision		Revision as of 14:52, 30 December 2023
Line 7:		Line 7:
	# '''S'''→'''C''': [[Protocol#Encryption Request\|Encryption Request]]		# '''S'''→'''C''': [[Protocol#Encryption Request\|Encryption Request]]
	# ''Client authentication''		# ''Client authentication''
	# '''S'''→'''C''': [[Protocol#Encryption Response\|Encryption Response]]		# '''C'''→'''S''': [[Protocol#Encryption Response\|Encryption Response]]
	# ''Server authentication, both enable encryption''		# ''Server authentication, both enable encryption''
	# '''S'''→'''C''': [[Protocol#Login Success\|Login Success]]		# '''S'''→'''C''': [[Protocol#Login Success\|Login Success]]

imported>Simpleauthority: Clarify AES/CFB feedback/segment size.

2023-11-20T23:28:36Z

Clarify AES/CFB feedback/segment size.

← Older revision		Revision as of 23:28, 20 November 2023
Line 49:		Line 49:

	On receipt of a Encryption Request from the server, the client will generate a random 16-byte shared secret, to be used with the AES/CFB8 stream cipher. It then encrypts it with the server's public key (PKCS#1 v1.5 padded), and also encrypts the verify token received in the Encryption Request packet in the same way, then sends both to the server in a Encryption Response packet. Both byte arrays in the Encryption Response packet will be 128 bytes long because of the padding. This is the only time the client uses the server's public key.		On receipt of a Encryption Request from the server, the client will generate a random 16-byte shared secret, to be used with the AES/CFB8 stream cipher. It then encrypts it with the server's public key (PKCS#1 v1.5 padded), and also encrypts the verify token received in the Encryption Request packet in the same way, then sends both to the server in a Encryption Response packet. Both byte arrays in the Encryption Response packet will be 128 bytes long because of the padding. This is the only time the client uses the server's public key.

			[[File:Icon_exclaim.gif\|:!:]] In your crypto library, ensure that you set up your "feedback/segment size" to 8 bits or 1 byte, as indicated in the name AES/CFB'''8'''. Any other feedback size will result in encryption mismatch.

	The server decrypts the shared secret and token using its private key, and checks if the token is the same. It then sends a Login Success, and enables AES/CFB8 encryption. For the Initial Vector (IV) and AES setup, both sides use the shared secret as both the IV and the key. Similarly, the client will also enable encryption upon sending Encryption Response. From this point forward, everything is encrypted. Note: the entire packet is encrypted, including the length fields and the packet's data.		The server decrypts the shared secret and token using its private key, and checks if the token is the same. It then sends a Login Success, and enables AES/CFB8 encryption. For the Initial Vector (IV) and AES setup, both sides use the shared secret as both the IV and the key. Similarly, the client will also enable encryption upon sending Encryption Response. From this point forward, everything is encrypted. Note: the entire packet is encrypted, including the length fields and the packet's data.

imported>PassTheMayo: Convert overview packet list to a linked list

2023-10-22T21:17:05Z

Convert overview packet list to a linked list

← Older revision		Revision as of 21:17, 22 October 2023
Line 2:		Line 2:

	== Overview ==		== Overview ==
	C->S : Handshake State=2
	C->S : Login Start		# '''C'''→'''S''': [[Protocol#Handshake\|Handshake]] State=2
	S->C : Encryption ~~Key~~ Request		# '''C'''→'''S''': [[Protocol#Login Start\|Login Start]]
	(Client ~~Auth)~~		# '''S'''→'''C''': [[Protocol#Encryption Request\|Encryption Request]]
	C~~->S~~ : Encryption ~~Key~~ Response		# ''Client authentication''
	(Server ~~Auth~~, ~~Both~~ enable encryption)		# '''S'''→'''C''': [[Protocol#Encryption Response\|Encryption Response]]
	S->C : Login Success		# ''Server authentication, both enable encryption''
	~~#see~~ [[Protocol FAQ]] ~~to get information about what happens next~~.		# '''S'''→'''C''': [[Protocol#Login Success\|Login Success]]

			See [[Protocol FAQ]] for a full list of packets exchanged after encryption.

	==Server ID String==		==Server ID String==

imported>LassiPulkkinen: Clarify public key encoding details, add links. Better not bombard novices with acronyms without making clear what is what.

2023-10-15T13:28:40Z

Clarify public key encoding details, add links. Better not bombard novices with acronyms without making clear what is what.

← Older revision		Revision as of 13:28, 15 October 2023
Line 23:		Line 23:
	== Key Exchange ==		== Key Exchange ==

	The server generates a 1024-bit RSA keypair on startup. The public key is sent in the Encryption Request packet in DER ~~encoding~~ format. ~~More technically, it~~ is in ~~ASN~~.~~1 format~~ as defined by x.509 ~~with the structure looking as follows~~.		The server generates a 1024-bit RSA keypair on startup. The public key sent in the Encryption Request packet is encoded in [https://en.wikipedia.org/wiki/ASN.1 ASN.1] [https://en.wikipedia.org/wiki/X.690#DER_encoding DER] format. This is a general-purpose binary format common in cryptography, conceptually similar to [[NBT]]. The schema is the same as the <code>SubjectPublicKeyInfo</code> structure defined by [https://en.wikipedia.org/wiki/X.509 X.509] (not a full-blown X.509 certificate!):

	SubjectPublicKeyInfo ::= SEQUENCE {		SubjectPublicKeyInfo ::= SEQUENCE {
Line 30:		Line 30:
	parameters ANY OPTIONAL		parameters ANY OPTIONAL
	}		}
	subjectPublicKey ~~BITSTRING~~		subjectPublicKey BIT STRING
	}		}

Line 37:		Line 37:
	publicExponent INTEGER		publicExponent INTEGER
	}		}

			(See the [[#Additional Links]] section of this article for further information.)

	If you're struggling to import this using a crypto library, try to find a function that loads a DER encoded public key. If you can't find one, you can convert it to the more common PEM encoding by base64-encoding the raw bytes and wrapping the base64 text in '-----BEGIN PUBLIC KEY-----' and '-----END PUBLIC KEY-----'. See this example of a PEM encoded key: https://git.io/v7Ol9		If you're struggling to import this using a crypto library, try to find a function that loads a DER encoded public key. If you can't find one, you can convert it to the more common PEM encoding by base64-encoding the raw bytes and wrapping the base64 text in '-----BEGIN PUBLIC KEY-----' and '-----END PUBLIC KEY-----'. See this example of a PEM encoded key: https://git.io/v7Ol9

	It is also possible for a modified or custom server to use a longer RSA key, without breaking ~~offical~~ clients.		It is also possible for a modified or custom server to use a longer RSA key, without breaking official clients.

	== Symmetric Encryption ==		== Symmetric Encryption ==

imported>Aaron: /* Client */ Add details about the session server rejecting requests from banned players

2022-07-30T07:43:35Z

Client: Add details about the session server rejecting requests from banned players

← Older revision		Revision as of 07:43, 30 July 2022
Line 91:		Line 91:
	{		{
	"error": "InsufficientPrivilegesException",		"error": "InsufficientPrivilegesException",
			"path": "/session/minecraft/join"
			}
			</syntaxhighlight>

			Similarly, if the player was banned from Multiplayer then the server will respond with the following error:
			<syntaxhighlight lang="javascript">
			{
			"error": "UserBannedException",
	"path": "/session/minecraft/join"		"path": "/session/minecraft/join"
	}		}

imported>Boom: Add details on when the auth server rejects the requests when the player has multiplayer disabled

2022-06-03T01:36:28Z

Add details on when the auth server rejects the requests when the player has multiplayer disabled

← Older revision		Revision as of 01:36, 3 June 2022
Line 86:		Line 86:

	If everything goes well, the client will receive a "HTTP/1.1 204 No Content" response.		If everything goes well, the client will receive a "HTTP/1.1 204 No Content" response.

			The server will respond with "HTTP/1.1 403 Forbidden" if the player's Xbox profile has multiplayer disabled, with the following response:
			<syntaxhighlight lang="javascript">
			{
			"error": "InsufficientPrivilegesException",
			"path": "/session/minecraft/join"
			}
			</syntaxhighlight>

	=== Server ===		=== Server ===