HTTPS Decode Via Pre-master secret - Revision history

Busk: Busk moved page Wireshark TLS Decode Windows IIS to HTTPS Decode Via Pre-master secret without leaving a redirect

2022-08-18T21:19:03Z

Busk moved page Wireshark TLS Decode Windows IIS to HTTPS Decode Via Pre-master secret without leaving a redirect

Busk at 21:18, 18 August 2022

2022-08-18T21:18:06Z

Busk at 16:02, 18 August 2022

2022-08-18T16:02:27Z

Busk at 19:56, 17 August 2022

2022-08-17T19:56:08Z

Busk at 18:23, 17 August 2022

2022-08-17T18:23:27Z

Busk at 18:19, 17 August 2022

2022-08-17T18:19:30Z

Busk at 17:43, 17 August 2022

2022-08-17T17:43:40Z

Busk at 16:46, 17 August 2022

2022-08-17T16:46:19Z

Busk at 16:22, 17 August 2022

2022-08-17T16:22:54Z

Busk at 16:06, 17 August 2022

2022-08-17T16:06:56Z

← Older revision		Revision as of 21:18, 18 August 2022
Line 1:		Line 1:
		+	https://crypto.stackexchange.com/questions/27131/differences-between-the-terms-pre-master-secret-master-secret-private-key
		+
	https://support.f5.com/csp/article/K50557518		https://support.f5.com/csp/article/K50557518

← Older revision		Revision as of 16:02, 18 August 2022
Line 1:		Line 1:
	https://support.f5.com/csp/article/K50557518		https://support.f5.com/csp/article/K50557518
		+
		+	https://support.f5.com/csp/article/K50557518#OnWindows

	https://serverfault.com/questions/1026728/nginx-post-ssl-termination-debug-mirror		https://serverfault.com/questions/1026728/nginx-post-ssl-termination-debug-mirror

← Older revision		Revision as of 19:56, 17 August 2022
Line 1:		Line 1:
		+	https://support.f5.com/csp/article/K50557518
		+
	https://serverfault.com/questions/1026728/nginx-post-ssl-termination-debug-mirror		https://serverfault.com/questions/1026728/nginx-post-ssl-termination-debug-mirror
	h		h

← Older revision		Revision as of 18:23, 17 August 2022
Line 1:		Line 1:
−	https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=89	+	https://serverfault.com/questions/1026728/nginx-post-ssl-termination-debug-mirror
		+	h
		+	ttps://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=89

	https://wiki.wireshark.org/TLS		https://wiki.wireshark.org/TLS

@@ Line 19: / Line 19: @@
 The SSL connection was probably using Diffie-Hellman to establish the session key. DH allows two parties to establish a shared secret over an insecure channel with no prior communication. This means that even though you have the private key, you can't determine the session key by inspecting the traffic. To decode a DH session you have to actively MITM the connection, or get one of the parties to log the session key.
 ```
 https://minnmyatsoe.com/2016/01/26/using-tshark-to-decrypt-ssl-tls-packets/

← Older revision	Revision as of 21:19, 18 August 2022
(No difference)

← Older revision		Revision as of 17:43, 17 August 2022
Line 21:		Line 21:

	https://minnmyatsoe.com/2016/01/26/using-tshark-to-decrypt-ssl-tls-packets/		https://minnmyatsoe.com/2016/01/26/using-tshark-to-decrypt-ssl-tls-packets/
		+
		+
		+
		+
		+
		+	```
		+	# [1] create RSA cert and key pair
		+	openssl req -new -x509 -out server.crt -nodes -keyout server.pem -subj /CN=localhost
		+
		+	# [2] run the server using the above
		+	openssl s_server -www -cipher AES256-SHA -key server.pem -cert server.crt -accept 4443
		+
		+	# [3] from another console session, start capturing the traffic, on loopback interface
		+	# (you will need to change lo0 to the relevant interface on your system.
		+	tshark -s0 -w ssltest.pcap -i lo0
		+
		+	# [4] generate traffic from another console
		+	curl -vk https://localhost:4443
		+
		+	# [5] Ctrl+C on the tshark command at [3], and stop the openssl server at [2]
		+	At this point, we should have the file called ssltest.pcap from tshark, and server.crt/server.pem from openssl commands.
		+
		+	Next, we are going to read the pcap file and decode the traffic.
		+
		+	# [1] it shows the encrypted traffic
		+	tshark -r ssltest.pcap
		+
		+	# [2] for details of the packets
		+	tshark -r ssltest.pcap -V
		+
		+	# [3] for decrypted data; ssl.keys_list points to the RSA key
		+	# added -x for hex dump
		+	# At the output you should see the message in packet detail:
		+	# >>> Decrypted SSL record (16 bytes):
		+	# And the decrypted data:
		+	# >>> Hypertext Transfer Protocol
		+	# >>> GET / HTTP/1.1\r\n
		+	tshark -r ssltest.pcap -V -x -o "ssl.debug_file:ssldebug.log" -o "ssl.desegment_ssl_records: TRUE" -o "ssl.desegment_ssl_application_data: TRUE" -o "ssl.keys_list:127.0.0.1,4443,http,server.pem"
		+
		+	# [4] inspecting ssldebug.log output from [3]
		+	# You should see the following messeage near the top of the file:
		+	# >>> ssl_init private key file server.pem successfully loaded.
		+	cat ssldebug.log
		+	In Wireshark GUI, we can follow “SSL stream” that will dump the ASCII output from the stream. How are we going to do it with tshark?
		+
		+	# We add -z to show the statistics with option 'follow,ssl,ascii,1'
		+	# to follow ssl stream number 1
		+	# -q to suppress packet dumps
		+	tshark -r sslsample.pcap -q -o "ssl.keys_list:127.0.0.1,4443,http,server.pem" -z "follow,ssl,ascii,1"
		+	You will see the output similar to below:
		+
		+	===================================================================
		+	Follow: ssl,ascii
		+	Filter: tcp.stream eq 1
		+	Node 0: 127.0.0.1:55041
		+	Node 1: 127.0.0.1:4443
		+	78
		+	GET / HTTP/1.1
		+	Host: localhost:4443
		+	User-Agent: curl/7.43.0
		+	Accept: /
		+
		+
		+	1802
		+	HTTP/1.0 200 ok
		+	Content-type: text/html
		+
		+
		+	<_pre>
		+
		+	s_server -www -cipher AES256-SHA -key server.pem -cert server.crt -accept 4443
		+	Ciphers supported in s_server binary
		+	TLSv1/SSLv3:AES256-SHA
		+	---
		+	Ciphers common between both SSL end points:
		+	ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-DES-CBC3-SHA
		+	ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-DES-CBC3-SHA
		+	ECDH-ECDSA-AES256-SHA ECDH-ECDSA-AES128-SHA ECDH-ECDSA-DES-CBC3-SHA
		+	ECDH-RSA-AES256-SHA ECDH-RSA-AES128-SHA ECDH-RSA-DES-CBC3-SHA
		+	DHE-RSA-AES256-SHA DHE-RSA-AES128-SHA EDH-RSA-DES-CBC3-SHA
		+	AES256-SHA AES128-SHA DES-CBC3-SHA
		+	ECDHE-ECDSA-RC4-SHA ECDHE-RSA-RC4-SHA ECDH-ECDSA-RC4-SHA
		+	ECDH-RSA-RC4-SHA RC4-SHA RC4-MD5
		+	---
		+	New, TLSv1/SSLv3, Cipher is AES256-SHA
		+	SSL-Session:
		+	Protocol : TLSv1
		+	Cipher : AES256-SHA
		+	Session-ID: B9AE3B24559606A2723F987F21E9C202EDB19366098286083F3BDCDABE45B300
		+	Session-ID-ctx: 01000000
		+	Master-Key: 98DC04D8CD7AE943A08BE013CD4C7D0608950BC201B953BC12755EC9B4804D453148173B00043EF6A01CAC43F7B0005C
		+	Key-Arg : None
		+	Start Time: 1453795701
		+	Timeout : 300 (sec)
		+	Verify return code: 0 (ok)
		+	---
		+	2 items in the session cache
		+	0 client connects (SSL_connect())
		+	0 client renegotiates (SSL_connect())
		+	0 client connects that finished
		+	2 server accepts (SSL_accept())
		+	0 server renegotiates (SSL_accept())
		+	2 server accepts that finished
		+	0 session cache hits
		+	0 session cache misses
		+	0 session cache timeouts
		+	0 callback cache hits
		+	0 cache full overflows (128 allowed)
		+	---
		+	no client certificate available
		+	```

← Older revision		Revision as of 16:46, 17 August 2022
Line 19:		Line 19:
	The SSL connection was probably using Diffie-Hellman to establish the session key. DH allows two parties to establish a shared secret over an insecure channel with no prior communication. This means that even though you have the private key, you can't determine the session key by inspecting the traffic. To decode a DH session you have to actively MITM the connection, or get one of the parties to log the session key.		The SSL connection was probably using Diffie-Hellman to establish the session key. DH allows two parties to establish a shared secret over an insecure channel with no prior communication. This means that even though you have the private key, you can't determine the session key by inspecting the traffic. To decode a DH session you have to actively MITM the connection, or get one of the parties to log the session key.
	```		```
		+
		+	https://minnmyatsoe.com/2016/01/26/using-tshark-to-decrypt-ssl-tls-packets/

← Older revision		Revision as of 16:22, 17 August 2022
Line 12:		Line 12:

	https://accedian.com/blog/how-to-decrypt-an-https-exchange-with-wireshark/		https://accedian.com/blog/how-to-decrypt-an-https-exchange-with-wireshark/
		+
		+	https://linuxhint.com/decrypt-ssl-tls-wireshark/

	https://superuser.com/questions/389475/decrypting-ssl-traffic-in-wireshark-only-headers-get-decrypted		https://superuser.com/questions/389475/decrypting-ssl-traffic-in-wireshark-only-headers-get-decrypted

← Older revision		Revision as of 16:06, 17 August 2022
Line 14:		Line 14:

	https://superuser.com/questions/389475/decrypting-ssl-traffic-in-wireshark-only-headers-get-decrypted		https://superuser.com/questions/389475/decrypting-ssl-traffic-in-wireshark-only-headers-get-decrypted
		+	```
		+	The SSL connection was probably using Diffie-Hellman to establish the session key. DH allows two parties to establish a shared secret over an insecure channel with no prior communication. This means that even though you have the private key, you can't determine the session key by inspecting the traffic. To decode a DH session you have to actively MITM the connection, or get one of the parties to log the session key.
		+	```