I'm trying to understang which TLS version is used based on this logs (http trace)
System.Net Information: 0 : [2544] SecureChannel#49129953::.AcquireClientCredentials, new SecureCredential() (flags=(ValidateManual, NoDefaultCred, SendAuxRecord), m_ProtocolFlags=(Ssl3Client, Tls10Client), m_EncryptionPolicy=RequireEncryption)
Algorithm: RSA
Length: 2048
Key Blob: 30 82 01 0a 02 82 01 01 00 b8 de 6a 2c a0 05 1d c1 2e 54 2d de 74 40 a6 83 2b 81 25 29 8d c1 2b e1 4d 4b 63 bd 7f c0 75 fe 15 eb 6b a6 2f 3c 65 d6 7a 55 dc 68 07 1c 6c 2e 8c cd d5 01 74 9f ca ca bb 5e b0 6d 9a 44 d1 1c 74 11 ca 4f 44 fa 59 59 22 f5 f9 c2 00 21 d6 1d a3 09 5a 0e fe da b7 ea d2 c8 55 51 c7 53 90 d1 b9 bf 2c 98 49 75 82 30 ....
System.Net Information: 0 : [2544] SecureChannel#49129953 - Remote certificate was verified as valid by the user.
System.Net Information: 0 : [2544] ProcessAuthentication(Protocol=Tls, Cipher=Aes128 128 bit strength, Hash=Sha1 160 bit strength, Key Exchange=RsaKeyX 2048 bit strength).
Any idea? If you need more log let me know.
Thank you
... m_ProtocolFlags=(Ssl3Client, Tls10Client)
... ProcessAuthentication(Protocol=Tls
Based on this it should be TLS 1.0. For other versions like TLS 1.2 there is probably something like Protocol=Tls12 instead
Related
im trying to reverse one app, and wanted to ask, maybe some one can help with fresh idea, or already know what is used here.
So the case, i have client and server, now i have written mitm app, and i can see the packets.
Tha packets order is
s2c: sending rsa key
c2s: sending some always static data, encrypted with rsa
s2c: sending some response, seems like an packet without body (im here)
c2s: sending data, and here is problem, that this packet is not encrypted as packet 2
c2s: sending response
this is packet header
50 50 00 00 40 00 50 00 00 00 00 00 ... rest is body
lets divide it
50 50 - this is always same
00 00 - this is some packet flag, cause always after packet 3, it becomes x04 00
40 00 - this is length 100%
50 00 - packet code i think
00 00 00 00 - i dont know what i this
body - is not readable, but also is not encrypted with rsa
here is example of stream
**s2c packet 1**
2023/01/24 21:32:56 Received: 176
00000000 *50 50 00 00 a4 00 01 00 00 00 00 00* a2 00 2d 2d |PP............--|
00000010 2d 2d 2d 42 45 47 49 4e 20 52 53 41 20 50 55 42 |---BEGIN RSA PUB|
00000020 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 45 63 |LIC KEY-----.MEc|
00000030 43 51 51 43 71 49 4e 36 37 76 45 52 47 37 34 49 |CQQCqIN67vERG74I|
00000040 64 77 38 6d 76 6c 66 6d 45 31 38 31 31 56 74 2b |dw8mvlfmE1811Vt+|
00000050 53 76 66 67 73 36 43 68 59 51 78 4e 5a 52 57 74 |Svfgs6ChYQxNZRWt|
00000060 7a 31 6f 62 50 53 69 34 62 75 78 72 41 0a 5a 6d |z1obPSi4buxrA.Zm|
00000070 6d 77 32 4e 69 38 44 59 74 67 6d 77 54 74 48 51 |mw2Ni8DYtgmwTtHQ|
00000080 66 6b 6d 35 65 59 2f 76 63 54 41 67 49 44 43 51 |fkm5eY/vcTAgIDCQ|
00000090 3d 3d 0a 2d 2d 2d 2d 2d 45 4e 44 20 52 53 41 20 |==.-----END RSA |
000000a0 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a |PUBLIC KEY-----.|
2023/01/24 21:32:56 RSA Key chaged - here i changed key to my
**c2s packet 2**
2023/01/24 21:32:56 Received: 76
00000000 *50 50 00 00 40 00 50 00 00 00 00 00* 97 4a 85 34 |PP..#.P......J.4|
00000010 e6 e0 f8 56 d6 5b 12 a4 4b 3f e2 f3 c7 b4 a1 fc |...V.[..K?......|
00000020 c7 fe b8 88 bc b7 8b 93 89 c2 7f 02 09 7b 52 4a |.............{RJ|
00000030 23 be a4 47 eb b8 02 f5 0a 62 9a 88 15 13 12 de |#..G.....b......|
00000040 a4 94 2c 3a 0a 34 47 bb 13 6f d4 ae |..,:.4G..o..|
2023/01/24 21:32:56 Header: 76
00000000 *50 50 00 00 40 00 50 00 00 00 00 00* |PP..#.P.....|
2023/01/24 21:32:56 Encoded with my key
00000000 *97 4a 85 34 e6 e0 f8 56 d6 5b 12 a4* 4b 3f e2 f3 |.J.4...V.[..K?..|
00000010 c7 b4 a1 fc c7 fe b8 88 bc b7 8b 93 89 c2 7f 02 |................|
00000020 09 7b 52 4a 23 be a4 47 eb b8 02 f5 0a 62 9a 88 |.{RJ#..G.....b..|
00000030 15 13 12 de a4 94 2c 3a 0a 34 47 bb 13 6f d4 ae |......,:.4G..o..|
2023/01/24 21:32:56 Decoded body
00000000 29 00 00 00 23 48 00 00 be 18 00 00 84 67 00 00 |)...#H.......g..|
2023/01/24 21:32:56 Encoded with original key
00000000 0a cb d2 7f f6 a3 8b 57 2c 6b e8 6d ed f0 c1 36 |.......W,k.m...6|
00000010 e4 c8 00 9d ca 55 41 62 ef 4b 72 91 7c fc 7b 1d |.....UAb.Kr.|.{.|
00000020 e4 5c f0 2b ce 86 01 79 ae b8 13 dd 51 a0 30 c5 |.\.+...y....Q.0.|
00000030 6f 77 fa 11 ed 03 7b 2c 77 7c 5b 7e 61 6f 86 9d |ow....{,w|[~ao..|
**s2c packet 3**
2023/01/24 21:32:56 Received: 12
00000000 *50 50 00 00 00 00 02 00 00 00 00 00* |PP..........|
**c2s packet 4**
2023/01/24 21:32:56 Not decoding next packet
2023/01/24 21:32:56 Received: 174
00000000 *50 50 04 00 a2 00 01 30 00 00 00 00* 00 9f 53 ab |PP.....0......S.|
00000010 c8 58 49 ea 4d fa 18 f4 f1 fc 9a 3c 04 ca 11 94 |.XI.M......<....|
00000020 ab ec ba 1d c6 f0 5d e0 1f d6 87 2d de 0c 97 eb |......]....-....|
00000030 29 b7 d1 dc 48 38 f4 63 74 29 e2 ea 9f 81 a8 59 |)...H8.ct).....Y|
00000040 47 75 32 0d 53 0e 55 3e cd 7b 89 d9 c3 22 d5 39 |Gu2.S.U>.{...".9|
00000050 c4 18 a5 c7 e2 eb 3a 9e 72 13 36 c3 52 f5 e6 7d |......:.r.6.R..}|
00000060 9b bf 37 06 e5 e9 4c 74 ac 85 37 85 94 81 37 67 |..7...Lt..7...7g|
00000070 f9 28 60 c7 0a ca 4c 5a 57 20 d6 ce 7c 91 58 6b |.(`...LZW ..|.Xk|
00000080 56 af 96 a8 e4 b5 8c 19 2e 9a 8c fa a6 c2 08 24 |V..............$|
00000090 ab 97 5d be 74 c2 19 d2 bd f1 93 5f a5 65 c5 7c |..].t......_.e.||
000000a0 fa bb 46 07 80 fd b6 79 5c 19 6f 65 54 35 |..F....y\.oeT5|
**s2c packet 5**
2023/01/24 21:32:56 Received: 174
00000000 *50 50 04 00 a2 00 01 40 00 00 00 00* 00 9e e7 03 |PP.....#........|
00000010 1b aa 67 36 1e 6f 34 20 c3 7c a9 85 93 74 b7 53 |..g6.o4 .|...t.S|
00000020 cc 10 68 90 ec 41 54 68 bb 9e 3d 41 c9 3f db 41 |..h..ATh..=A.?.A|
00000030 09 b9 ae 6a 9b f9 5c 0f 47 c6 4b bd 94 08 20 b0 |...j..\.G.K... .|
00000040 2e f2 6e 40 11 b6 14 8b e0 51 89 db 0c e0 c8 5b |..n#.....Q.....[|
00000050 92 1f a3 08 90 05 5c b5 bb bb 50 c0 3e f6 ee e8 |......\...P.>...|
00000060 63 bd 23 74 53 24 8f a3 0b 4e 72 12 a0 0e ac 96 |c.#tS$...Nr.....|
00000070 03 2c e8 31 6a 34 10 84 63 7a e1 32 42 d3 69 17 |.,.1j4..cz.2B.i.|
00000080 73 df a4 89 35 90 0f 92 06 d7 3b 2e 3c 3d 6e 7e |s...5.....;.<=n~|
00000090 db 73 cb f0 96 95 df 84 af 20 b7 7b 7c 64 61 a9 |.s....... .{|da.|
000000a0 b2 0e 9d 1e bc 57 73 5f f0 bc a5 aa b8 36 |.....Ws_.....6|
Maybe some one can identify protocol by packet header, cause i havent seen something similar before.
Thank you
i know that only packet 2 is encrypted, cause i changed rsa key to my key, and decoded data, its not work with other packets.
How does the server using the Certificate Private Key to create Certificate Verify message in TLS 1.3? And how the Client using the Certificate public key to verify the handshake not to be modify? Just in TLS 1.3 not TLS 1.2
As a good overview of the phases of the TLS 1.3 handshake I like to use this site, which breaks down the connection to easier to understand phases then going through the RFC's.
From the above site:
Signature
Because the server is generating ephemeral keys for each
session (optional in TLS 1.2, mandatory in TLS 1.3) the session is not
inherently tied to the certificate as it was in previous versions of
TLS, when the certificate's public/private key were used for key
exchange.
To prove that the server owns the server certificate (giving the
certificate validity in this TLS session), it signs a hash of the
handshake messages using the certificate's private key. The signature
can be proven valid by the client by using the certificate's public
key. 08 04 - reserved value for RSA-PSS-RSAE-SHA256 signature 01 00
- 0x100 (256) bytes of signature data follows 17 fe b5 ... 36 9f 9e - a signature over this handshake's hash We can verify the signature
ourselves using the server's certificate at the command line:
build the data that was signed:
1. add 64 space characters
$ echo -n ' ' > /tmp/tosign
$ echo -n ' ' >> /tmp/tosign
2. add this fixed string
$ echo -n 'TLS 1.3, server CertificateVerify' >> /tmp/tosign
3. add a single null character
$ echo -en '\0' >> /tmp/tosign
4. add hash of handshake to this point
$ handshake_hash=3e66361ada42c7cb97f9a62b00cae1d8b584174c745f9a338cf9f7cdd51d15f8
$ echo $handshake_hash | xxd -r -p >> /tmp/tosign
copy the signature that we want to verify
$ echo "17 fe b5 33 ca 6d 00 7d 00 58 25 79 68 42 4b bc 3a a6 90
9e 9d 49 55 75 76 a5 20 e0 4a 5e f0 5f 0e 86 d2 4f f4 3f 8e b8 61
ee f5 95 22 8d 70 32 aa 36 0f 71 4e 66 74 13 92 6e f4 f8 b5 80 3b
69 e3 55 19 e3 b2 3f 43 73 df ac 67 87 06 6d cb 47 56 b5 45 60 e0
88 6e 9b 96 2c 4a d2 8d ab 26 ba d1 ab c2 59 16 b0 9a f2 86 53 7f
68 4f 80 8a ef ee 73 04 6c b7 df 0a 84 fb b5 96 7a ca 13 1f 4b 1c
f3 89 79 94 03 a3 0c 02 d2 9c bd ad b7 25 12 db 9c ec 2e 5e 1d 00
e5 0c af cf 6f 21 09 1e bc 4f 25 3c 5e ab 01 a6 79 ba ea be ed b9
c9 61 8f 66 00 6b 82 44 d6 62 2a aa 56 88 7c cf c6 6a 0f 38 51 df
a1 3a 78 cf f7 99 1e 03 cb 2c 3a 0e d8 7d 73 67 36 2e b7 80 5b 00
b2 52 4f f2 98 a4 da 48 7c ac de af 8a 23 36 c5 63 1b 3e fa 93 5b
b4 11 e7 53 ca 13 b0 15 fe c7 e4 a7 30 f1 36 9f 9e" | xxd -r -p > /tmp/sig
extract the public key from the certificate
$ openssl x509 -pubkey -noout -in server.crt > server.pub
verify the signature
$ cat /tmp/tosign | openssl dgst -verify server.pub -sha256 \
-sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature /tmp/sig
Verified OK
Where can i find some documentation on the format of an RSA public key?
An RSA public key formatted by OpenSSH:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQB/nAmOjTmezNUDKYvEeIRf2YnwM9/uUG1d0BYsc8/tRtx+RGi7N2lUbp728MXGwdnL9od4cItzky/zVdLZE2cycOa18xBK9cOWmcKS0A8FYBxEQWJ/q9YVUgZbFKfYGaGQxsER+A0w/fX8ALuk78ktP31K69LcQgxIsl7rNzxsoOQKJ/CIxOGMMxczYTiEoLvQhapFQMs3FL96didKr/QbrfB1WT6s3838SEaXfgZvLef1YB2xmfhbT9OXFE3FXvh2UPBfN+ffE7iiayQf/2XR+8j4N4bW30DiPtOQLGUrH1y5X/rpNZNlWW2+jGIxqZtgWg7lTy3mXy5x836Sj/6L
The same public key formatted for use in Secure Shell (RFC 4716 - The Secure Shell (SSH) Public Key File Format):
---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAABJQAAAQB/nAmOjTmezNUDKYvEeIRf2YnwM9/uUG1d0BYs
c8/tRtx+RGi7N2lUbp728MXGwdnL9od4cItzky/zVdLZE2cycOa18xBK9cOWmcKS
0A8FYBxEQWJ/q9YVUgZbFKfYGaGQxsER+A0w/fX8ALuk78ktP31K69LcQgxIsl7r
NzxsoOQKJ/CIxOGMMxczYTiEoLvQhapFQMs3FL96didKr/QbrfB1WT6s3838SEaX
fgZvLef1YB2xmfhbT9OXFE3FXvh2UPBfN+ffE7iiayQf/2XR+8j4N4bW30DiPtOQ
LGUrH1y5X/rpNZNlWW2+jGIxqZtgWg7lTy3mXy5x836Sj/6L
---- END SSH2 PUBLIC KEY ----
The same public key formatted as an RSA public key (note the five -, and no space):
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEA+xGZ/wcz9ugFpP07Nspo6U17l0YhFiFpxxU4pTk3Lifz9R3zsIsu
ERwta7+fWIfxOo208ett/jhskiVodSEt3QBGh4XBipyWopKwZ93HHaDVZAALi/2A
+xTBtWdEo7XGUujKDvC2/aZKukfjpOiUI8AhLAfjmlcD/UZ1QPh0mHsglRNCmpCw
mwSXA9VNmhz+PiB+Dml4WWnKW/VHo2ujTXxq7+efMU4H2fny3Se3KYOsFPFGZ1TN
QSYlFuShWrHPtiLmUdPoP6CV2mML1tk+l7DIIqXrQhLUKDACeM5roMx0kLhUWB8P
+0uj1CNlNN4JRZlC7xFfqiMbFRU9Z4N6YwIDAQAB
-----END RSA PUBLIC KEY-----
The hex dump of the base-64 encoded data:
00 00 00 07 73 73 68 2d 72 73 61 00 00 00 01 25 00 00 01 00 7f 9c 09
8e 8d 39 9e cc d5 03 29 8b c4 78 84 5f d9 89 f0 33 df ee 50 6d 5d d0
16 2c 73 cf ed 46 dc 7e 44 68 bb 37 69 54 6e 9e f6 f0 c5 c6 c1 d9 cb
f6 87 78 70 8b 73 93 2f f3 55 d2 d9 13 67 32 70 e6 b5 f3 10 4a f5 c3
96 99 c2 92 d0 0f 05 60 1c 44 41 62 7f ab d6 15 52 06 5b 14 a7 d8 19
a1 90 c6 c1 11 f8 0d 30 fd f5 fc 00 bb a4 ef c9 2d 3f 7d 4a eb d2 dc
42 0c 48 b2 5e eb 37 3c 6c a0 e4 0a 27 f0 88 c4 e1 8c 33 17 33 61 38
84 a0 bb d0 85 aa 45 40 cb 37 14 bf 7a 76 27 4a af f4 1b ad f0 75 59
3e ac df cd fc 48 46 97 7e 06 6f 2d e7 f5 60 1d b1 99 f8 5b 4f d3 97
14 4d c5 5e f8 76 50 f0 5f 37 e7 df 13 b8 a2 6b 24 1f ff 65 d1 fb c8
f8 37 86 d6 df 40 e2 3e d3 90 2c 65 2b 1f 5c b9 5f fa e9 35 93 65 59
6d be 8c 62 31 a9 9b 60 5a 0e e5 4f 2d e6 5f 2e 71 f3 7e 92 8f fe 8b
i've read that there are a couple of formats🕗:
Key data may be encoded in three general ways:
Binary DER-encoded format. This is sometimes called ASN.1 BER-encoded
PEM or base64 format. This is the same data as the DER-encoded file but it is encoded in base64 with additional header and footer lines
XML format.
If it's ASN.1, the hex certainly doesn't look like it.
What's the format of an RSA public key?
See also
RSA Key Formats
Abstract Syntax Notation One
Convert Base64 Public Key to XML Signature 🕗
Decode PEM formats
You can't just change the delimiters from ---- BEGIN SSH2 PUBLIC KEY ---- to -----BEGIN RSA PUBLIC KEY----- and expect that it will be sufficient to convert from one format to another (which is what you've done in your example).
This article has a good explanation about both formats.
What you get in an RSA PUBLIC KEY is closer to the content of a PUBLIC KEY, but you need to offset the start of your ASN.1 structure to reflect the fact that PUBLIC KEY also has an indicator saying which type of key it is (see RFC 3447). You can see this using openssl asn1parse and -strparse 19, as described in this answer.
EDIT: Following your edit, your can get the details of your RSA PUBLIC KEY structure using grep -v -- ----- | tr -d '\n' | base64 -d | openssl asn1parse -inform DER:
0:d=0 hl=4 l= 266 cons: SEQUENCE
4:d=1 hl=4 l= 257 prim: INTEGER :FB1199FF0733F6E805A4FD3B36CA68E94D7B974621162169C71538A539372E27F3F51DF3B08B2E111C2D6BBF9F5887F13A8DB4F1EB6DFE386C92256875212DDD00468785C18A9C96A292B067DDC71DA0D564000B8BFD80FB14C1B56744A3B5C652E8CA0EF0B6FDA64ABA47E3A4E89423C0212C07E39A5703FD467540F874987B209513429A90B09B049703D54D9A1CFE3E207E0E69785969CA5BF547A36BA34D7C6AEFE79F314E07D9F9F2DD27B72983AC14F1466754CD41262516E4A15AB1CFB622E651D3E83FA095DA630BD6D93E97B0C822A5EB4212D428300278CE6BA0CC7490B854581F0FFB4BA3D4236534DE09459942EF115FAA231B15153D67837A63
265:d=1 hl=2 l= 3 prim: INTEGER :010001
To decode the SSH key format, you need to use the data format specification in RFC 4251 too, in conjunction with RFC 4253:
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
mpint n
For example, at the beginning, you get 00 00 00 07 73 73 68 2d 72 73 61. The first four bytes (00 00 00 07) give you the length. The rest is the string itself: 73=s, 68=h, ... -> 73 73 68 2d 72 73 61=ssh-rsa, followed by the exponent of length 1 (00 00 00 01 25) and the modulus of length 256 (00 00 01 00 7f ...).
Starting from the decoded base64 data of an OpenSSL rsa-ssh Key, i've been able to guess a format:
00 00 00 07: four byte length prefix (7 bytes)
73 73 68 2d 72 73 61: "ssh-rsa"
00 00 00 01: four byte length prefix (1 byte)
25: RSA Exponent (e): 25
00 00 01 00: four byte length prefix (256 bytes)
RSA Modulus (n):
7f 9c 09 8e 8d 39 9e cc d5 03 29 8b c4 78 84 5f
d9 89 f0 33 df ee 50 6d 5d d0 16 2c 73 cf ed 46
dc 7e 44 68 bb 37 69 54 6e 9e f6 f0 c5 c6 c1 d9
cb f6 87 78 70 8b 73 93 2f f3 55 d2 d9 13 67 32
70 e6 b5 f3 10 4a f5 c3 96 99 c2 92 d0 0f 05 60
1c 44 41 62 7f ab d6 15 52 06 5b 14 a7 d8 19 a1
90 c6 c1 11 f8 0d 30 fd f5 fc 00 bb a4 ef c9 2d
3f 7d 4a eb d2 dc 42 0c 48 b2 5e eb 37 3c 6c a0
e4 0a 27 f0 88 c4 e1 8c 33 17 33 61 38 84 a0 bb
d0 85 aa 45 40 cb 37 14 bf 7a 76 27 4a af f4 1b
ad f0 75 59 3e ac df cd fc 48 46 97 7e 06 6f 2d
e7 f5 60 1d b1 99 f8 5b 4f d3 97 14 4d c5 5e f8
76 50 f0 5f 37 e7 df 13 b8 a2 6b 24 1f ff 65 d1
fb c8 f8 37 86 d6 df 40 e2 3e d3 90 2c 65 2b 1f
5c b9 5f fa e9 35 93 65 59 6d be 8c 62 31 a9 9b
60 5a 0e e5 4f 2d e6 5f 2e 71 f3 7e 92 8f fe 8b
The closest validation of my theory i can find it from RFC 4253:
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
mpint n
Here the 'e' and 'n' parameters form the signature key blob.
But it doesn't explain the length prefixes.
Taking the random RSA PUBLIC KEY i found (in the question), and decoding the base64 into hex:
30 82 01 0a 02 82 01 01 00 fb 11 99 ff 07 33 f6 e8 05 a4 fd 3b 36 ca 68
e9 4d 7b 97 46 21 16 21 69 c7 15 38 a5 39 37 2e 27 f3 f5 1d f3 b0 8b 2e
11 1c 2d 6b bf 9f 58 87 f1 3a 8d b4 f1 eb 6d fe 38 6c 92 25 68 75 21 2d
dd 00 46 87 85 c1 8a 9c 96 a2 92 b0 67 dd c7 1d a0 d5 64 00 0b 8b fd 80
fb 14 c1 b5 67 44 a3 b5 c6 52 e8 ca 0e f0 b6 fd a6 4a ba 47 e3 a4 e8 94
23 c0 21 2c 07 e3 9a 57 03 fd 46 75 40 f8 74 98 7b 20 95 13 42 9a 90 b0
9b 04 97 03 d5 4d 9a 1c fe 3e 20 7e 0e 69 78 59 69 ca 5b f5 47 a3 6b a3
4d 7c 6a ef e7 9f 31 4e 07 d9 f9 f2 dd 27 b7 29 83 ac 14 f1 46 67 54 cd
41 26 25 16 e4 a1 5a b1 cf b6 22 e6 51 d3 e8 3f a0 95 da 63 0b d6 d9 3e
97 b0 c8 22 a5 eb 42 12 d4 28 30 02 78 ce 6b a0 cc 74 90 b8 54 58 1f 0f
fb 4b a3 d4 23 65 34 de 09 45 99 42 ef 11 5f aa 23 1b 15 15 3d 67 83 7a
63 02 03 01 00 01
From RFC3447 - Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1:
A.1.1 RSA public key syntax
An RSA public key should be represented with the ASN.1 type RSAPublicKey:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
The fields of type RSAPublicKey have the following meanings:
modulus is the RSA modulus n.
publicExponent is the RSA public exponent e.
Using Microsoft's excellent (and the only real) ASN.1 documentation:
30 82 01 0a ;SEQUENCE (0x010A bytes: 266 bytes)
| 02 82 01 01 ;INTEGER (0x0101 bytes: 257 bytes)
| | 00 ;leading zero because high-bit, but number is positive
| | fb 11 99 ff 07 33 f6 e8 05 a4 fd 3b 36 ca 68
| | e9 4d 7b 97 46 21 16 21 69 c7 15 38 a5 39 37 2e 27 f3 f5 1d f3 b0 8b 2e
| | 11 1c 2d 6b bf 9f 58 87 f1 3a 8d b4 f1 eb 6d fe 38 6c 92 25 68 75 21 2d
| | dd 00 46 87 85 c1 8a 9c 96 a2 92 b0 67 dd c7 1d a0 d5 64 00 0b 8b fd 80
| | fb 14 c1 b5 67 44 a3 b5 c6 52 e8 ca 0e f0 b6 fd a6 4a ba 47 e3 a4 e8 94
| | 23 c0 21 2c 07 e3 9a 57 03 fd 46 75 40 f8 74 98 7b 20 95 13 42 9a 90 b0
| | 9b 04 97 03 d5 4d 9a 1c fe 3e 20 7e 0e 69 78 59 69 ca 5b f5 47 a3 6b a3
| | 4d 7c 6a ef e7 9f 31 4e 07 d9 f9 f2 dd 27 b7 29 83 ac 14 f1 46 67 54 cd
| | 41 26 25 16 e4 a1 5a b1 cf b6 22 e6 51 d3 e8 3f a0 95 da 63 0b d6 d9 3e
| | 97 b0 c8 22 a5 eb 42 12 d4 28 30 02 78 ce 6b a0 cc 74 90 b8 54 58 1f 0f
| | fb 4b a3 d4 23 65 34 de 09 45 99 42 ef 11 5f aa 23 1b 15 15 3d 67 83 7a
| | 63
| 02 03 ;INTEGER (3 bytes)
| 01 00 01
giving the public key modulus and exponent:
modulus = 0xfb1199ff0733f6e805a4fd3b36ca68...837a63
exponent = 65,537
Update: My expanded form of this answer in another question
Reference Decoder of CRL,CRT,CSR,NEW CSR,PRIVATE KEY, PUBLIC KEY,RSA,RSA Public Key Parser
RSA Public Key
-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----
Encrypted Private Key
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
-----END RSA PRIVATE KEY-----
CRL
-----BEGIN X509 CRL-----
-----END X509 CRL-----
CRT
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
CSR
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
NEW CSR
-----BEGIN NEW CERTIFICATE REQUEST-----
-----END NEW CERTIFICATE REQUEST-----
PEM
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
PKCS7
-----BEGIN PKCS7-----
-----END PKCS7-----
PRIVATE KEY
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
DSA KEY
-----BEGIN DSA PRIVATE KEY-----
-----END DSA PRIVATE KEY-----
Elliptic Curve
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----
PGP Private Key
-----BEGIN PGP PRIVATE KEY BLOCK-----
-----END PGP PRIVATE KEY BLOCK-----
PGP Public Key
-----BEGIN PGP PUBLIC KEY BLOCK-----
-----END PGP PUBLIC KEY BLOCK-----
In wireshark, I am able to see the encrypted data to and fro from my PC. It does not use diffie hellman algorihm for key exchange because I see only the Client Key Exchange packet but there is no Server Key Exchange packet. That means the browser is sending the encrypted key to the server(encrypted using the server's public key).
But I do not see any encrypted data in that packet("Client Key Exchange"). How to view the encrypted key?
You won't see the encrypted shared-key, it's not exchanged. You can see the encrypted pre-master secret when using RSA authenticated key exchange. (Note that using Ephemeral Diffie-Hellman isn't the only reason for not seeing a server key exchange message: it could also use a DH_DSS or DH_RSA cipher suite, but this is unusual as far as I know).
If you follow the instructions about decrypting SSL with Wireshark, use the "SSL debug file" option to store the logs into a file. (Note that the user interface has changed slightly in newer versions of Wireshark, in the way you configure the private key.)
The log files will contain the pre-master secret and the shared keys.
(By the way, you need the server's private key to do this, of course.)
Using the sample data provided on the Wireshark page, you get:
pre master encrypted[128]:
65 51 2d a6 d4 a7 38 df ac 79 1f 0b d9 b2 61 7d
73 88 32 d9 f2 62 3a 8b 11 04 75 ca 42 ff 4e d9
cc b9 fa 86 f3 16 2f 09 73 51 66 aa 29 cd 80 61
0f e8 13 ce 5b 8e 0a 23 f8 91 5e 5f 54 70 80 8e
7b 28 ef b6 69 b2 59 85 74 98 e2 7e d8 cc 76 80
e1 b6 45 4d c7 cd 84 ce b4 52 79 74 cd e6 d7 d1
9c ad ef 63 6c 0f f7 05 e4 4d 1a d3 cb 9c d2 51
b5 61 cb ff 7c ee c7 bc 5e 15 a3 f2 52 0f bb 32
pre master secret[48]:
03 00 ff 84 56 6d a0 fb cc fd c6 c8 20 d5 f0 65
18 87 b0 44 45 9c e3 92 f0 4d 32 cd 41 85 10 24
cb 7a b3 01 36 3d 93 27 12 a4 7e 00 29 96 59 d8
master secret[48]:
1e db 35 95 b8 18 b3 52 58 f3 07 3f e6 af 8a a6
ab c3 a4 ed 66 3a 46 86 b6 e5 49 2a 7c f7 8c c2
ac 22 bb 13 15 0f d8 62 a2 39 23 7b c2 ff 28 fb
key expansion[136]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7
b3 f7 33 aa b2 42 d0 1c a6 4e fb e9 9b 13 dd 29
63 aa 17 1f 47 71 95 71 08 e0 4b 8e e1 da 7b 4a
5a f3 c2 32 bd e0 a5 82 6d 14 44 3a d6 cb 2d c0
7d 57 be a8 37 de 5d d9 a1 07 fd 1b 22 71 b9 4b
7a 1e 0f 70 37 14 97 0a f0 db 98 3b 7b 74 e3 2d
51 66 2e 31 68 90 ac 6f e6 53 3c c9 5e 48 0c 05
bc 9f 92 e7 f9 91 98 f5 95 1c c4 bf d9 cb 26 ef
35 70 5e ad 21 22 3e f6
Client MAC key[20]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7
b3 f7 33 aa
Server MAC key[20]:
b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 63 aa 17 1f
47 71 95 71
Client Write key[32]:
08 e0 4b 8e e1 da 7b 4a 5a f3 c2 32 bd e0 a5 82
6d 14 44 3a d6 cb 2d c0 7d 57 be a8 37 de 5d d9
Server Write key[32]:
a1 07 fd 1b 22 71 b9 4b 7a 1e 0f 70 37 14 97 0a
f0 db 98 3b 7b 74 e3 2d 51 66 2e 31 68 90 ac 6f
Client Write IV[16]:
e6 53 3c c9 5e 48 0c 05 bc 9f 92 e7 f9 91 98 f5
Server Write IV[16]:
95 1c c4 bf d9 cb 26 ef 35 70 5e ad 21 22 3e f6
Until recently the dissection of the ClientKeyExchange was like this(version 1.6 and below):
TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 134
Handshake Protocol: Client Key Exchange
Handshake Type: Client Key Exchange (16)
Length: 130
But if you use this verison(1.7.2 upwards) the key dissection will be like this:
TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 134
Handshake Protocol: Client Key Exchange
Handshake Type: Client Key Exchange (16)
Length: 130
RSA Encrypted PreMaster Secret
Encrypted PreMaster length: 128
Encrypted PreMaster: 761b1beac35e59de9a3bb9f74ebf9109b738e8ad346
You can see the encrypted pre-master:)
Awesome write up here explaining how SSL works, notice at no time during this handshake is the private key ever sent over the wire.
http://4orensics.wordpress.com/2011/10/21/ssl-in-a-nutshell/
Long story short there is no way to decrypt SSL streams without the server's private key (unless you work for the NSA or something), however you may want to look into getting in between the server and client during the handshake and if the user does not check the validity of the certificate that is presented you are in business.
Here is a tool that can do that for you among many others
http://mitmproxy.org/
Of note I highly recommend the sans reading room article on SSL Mitm(Man in the Middle) attacks.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have a file givin to me as a project, it has an unknown encryption type and is compressed. The compression type used is Zlib but the ratio is unknown. I have attempted to decompress the file and have produced 30 1kb files. I am unsure if the file is compressed then encrypted or vice versa.
I was given this output as a clue which I assume is produced in Bash shell Linux. I have cygwin installed in my Win machine and I'm using Bash, however I was unable to reproduce this ouput.
The file in question is a .FF which I assume stands for fastfile. I have included a hex snippet at the bottom of this thread.
$ ls -l bin.bin
-rw-r--r-- 1 sc sc 17150 2010-11-23 18:51 bin.bin
$ zip bin.zip bin.bin
adding: bin.bin (deflated 20%)
$ ./a.out < bin.bin | sort -k2rn | head -20
C3: 2756
C2: 1534
E2: 756
80: 709
C5: 294
A2: 185
A1: 158
A6: 154
BD: 149
AC: 140
B9: 133
93: 128
92: 127
9C: 127
B0: 127
A0: 121
BE: 121
B8: 120
9D: 116
BA: 116
49 57 66 66 30 31 30 30 00 00 01 D9 00 00 00 02 50 48 45 45 42 73 37 31 00 00 00 00 70 61 74 63 68 5F 6D 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A0 FA C7 BF 09 FC 57 8D 0E 0B 9B 3F 24 D2 FC 12 CC 78 71 2C BC 06 78 A0 3B 41 CA 92 19 C5 E8 3B 32 9D 39 ED 68 32 98 38 EB 8D DC D8 02 62 91 83 77 BA C4 3D 81 CD C0 0A F0 00 55 A3 6A 8A 9D 4D C8 C7 3D 8F 02 4A E4 FB EF F8 6A AA 33 95 AA DB DC 82 90 16 DC BD 9F 65 A1 70 07 8F 4A BE A4 83 DA AA 4F 84 8A 9D A0 5E 5E B1 54 9C C7 99 F8 83 74 71 B3 F9 46 D2 C5 22 7B 66 97 BA 47 89 1C FB DB D9 21 D3 B3 E6 93 5F 26 98 A1 42 E3 A5 D8 99 08 56 55 4F 5D F7 19 BA 79 9A BD 53 CE 6B 5A DA 84 F8 E2 F9 86 A0 7F 49 FD B9 95 33 02 E4 4B 2C 94 5F 95 25 7D E6 31 EB 43 4C 46 AE C4 4D 5C 5A B2 B2 EC 74 8D 07 D4 C7 6C E1 F4 B2 CF A4 B4 EA 4B BB 46 58 81 C4 5A CE 56 CE 8E 0B E0 10 2A 18 20 EB 09 F4 B2 A5 43 3E F8 0B 20 10 05 D8 03 EF CD F2 55 1C 4C 54 B1 A2 67 E4 F6 84 B7 8E 08 2A 00 00 00 17 66 40 A2 AF 03 82 81 08 C4 A9 C8 DF 48 56 56 ED FD 4D BA 8E F9 9A BE 00 00 2F 5E 79 A8 9C 56 BC 76 53 3F F8 F5 95 BE 97 57 95 93 E6 F0 AC D8 F1 11 45 C3 94 57 69 0B F3 68 30 EF 13 23 3C B9 50 7A AA 8A 16 74 59 E3 8E F1 F2 70 DA ED 3A F7 00 87 AA 81 93 4C 3F 1E 4F 2D B8 F1 EF A4 0E 6A E5 1A 0F 81 41 EF 79 C0 C6 B4 14 CB 81 5D B2 90 10 54 9E ED 05 00 06 AF 16 AD 74 49 3B A8 D0 3E B3 C0 68 3F 18 A7 77 15 68 F3 79 EC D5 8E 10 AD 8E 80 E8 1A 7D 0C B2 97 A3 52 5F DF AD 28 81 68 34 50 6C 16 18 01 08 1A 95 FF 15 06 93 3E 91 92 AE 2E 7B CA C9 C7 78 6F 69 9F D1 E1 58 32 9C 66 A1 BA F7 25 E3 8E 8F 70 80 8A 25 70 CC 1F 8D 1E D4 E2 91 6F 36 22 07 A7 E8 D5 16 D2 30 A3 82 6A 34 6B 86 FB A5 FE 6E 9B 96 FF EC 9A 5C B6 4B 18 57 4B 7C 36 BC 40 A6 17 F4 EE 39 F6 D1 86 FE C2 4F 51 DC 79 5B E3 1A C4 3E D1 7C 42 73 9A D2 D9 A6 BE 58 E1 BF FF 30 1B AE B2 BD B0 07 AA C2 E5 7D AF 6C FF A7 78 80 C6 5B 68 CD E3 A8 EF 03 7C 01 A7 A1 1A B1 D2 5C 98 20 E1 8D D5 E8 4E CD C2 DB AF 33 BF BF 79 C2 00 E3 E4 E2 0A D5 43 EF 35 8F 1D 07 6F D4 16 3E C9 5E 63 FE 74 7D 94 84 B0 58 79 08 E4 7D C2 80 0F AC 91 F8 58 27 6D A4 BD 83 4D 2B B4 7C B6 FF DA 74 D2 34 0B E4 8E DC 65 73 CE 7C 0E 25 58 2B 95 5B 08 40 27 D1 C2 22 67 32 59 27 98 0D 43 5A 15 0F FE 9C EC 8C E4 4E 9E B1 39 0F 67 54 3B B4 DF 3F 27 75 52 07 43 6A 27 3C 2C 4B 07 EC FE E5 ED 52 26 0D CF 29 06 75 16 91 96 63 09 B5 24 DC 8D 83 5E 08 42 82 48 1B 64 6B 55 46 35 0F 18 D6 85 87 4B CE 66 9E 8A 46 70 EF F3 18 E0 58 8C AD CE CF C6 BD F3 6F BE C5 F9 FB 63 B9 A4 34 6E 79 35 17 56 28 72 15 5D 93 57 C6 18 BA AE 31 CA 4B 43 C3 3C 73 F5 B1 A5 8B 25 B6 48 91 75 34 DA A0 86 74 BB 8B 9A 0C 00 32 D8 8E F9 EB 24 08 3D A4 1A 0A 54 B4 8A CF 57 82 BE 0D F9 43 0C A7 D0 97 47 50 23 4A FE 00 D9 10 55 EB 2C 79 60 E2 9A 47 47 57 EC EC 3D BB DA 33 73 92 2D DC C7 D6 73 04 42 6B 8D CB EA 15 EF 4D F3 B9 1A 89 3E 55 6E 73 1F 4D 8F 16 D9 FE 6E 88 D2 27 05 C1 B1 DE 6E DC 1A 95 B3 76 66 20 F4 DF A4 08 78 E0 4C D7 44 42 5A DE E9 63 AE 43 E5 E9 C2 CB 79 FA 5B 28 72 66 A9 29 88 3B 74 27 02 78 EC 53 69 AE 3D E6 66 F6 7F B4 43 A8 B8 BE 32 AE 6D E6 C2 FA 9C 9D 43 E2 A4 7F 22 6E 5C 6A 55 77 A4 C5 DB 5C D5 21 AD 54 F2 9B C6 C7 46 97 03 11 07 D3 3B 59 62 E8 7E 5C 92 DB A5 ED F2 CA 15 76 37 D2 E5 04 69 D5 18 27 39 3A 2C 61 55 22 F6 86 AD 28 70 48 DA ED 15 A6 9B 24 0D BA 35 31 54 55 7B 95 6A CB 60 E3 13 09 DA 8A 68 9D 96 52 AD A1 50 7B 43 06 A9 DE 62 85 88 C7 69 5F 42 3E CC D1 E6 CA 06 D1 AC 62 4D 96 41 97 29 B1 90 F8 D1 2A 70 74 DC E4 37 E8 14 CA 4F 12 3F 75 83 7D 23 48 30
I think this'll be somewhat out of SO's league. We're programmers, not cryptographers. With an unknown encryption, and unknown compression, you might as well give up. Even if it's something standard like AES or 3-DES, the odds of being able to recover a key that would decrypt into something legible are basically 0.
Even if it's something simplistic like XOR, the odds of finding the key string are low without any hint as to what the plaintext is. Was it encrypted with a single-byte? two bytes? 50 kilobyte? Perhaps it was a one-time-pad, in which case it's essentially impossible to decrypt without the original pad.
Any good crypto program isn't going to leave any plaintext or almost-plaintext signatures in the file to be spotted - that just gives a crack for a cryptographer to wedge their tools into and start prying.
According to the internets this is a (console) patch file.
Check this link for details (found via Google)
There also seems to be viewer available:
FFViewer