I have a digital signature (RSA - PKCS#1). After decrypting it with the RSA public key I get the following 128 bytes
00 01 ff ff ff .. ff 00 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 77 51 1b f4 d7 17 d7 ad 8c 2d e5 89 2a ca e0 6d a3 c0 7d 13 4d d7 b8 01 14 87 03 00 69 e4 9b b3
PKCS#1 padding removed, 51 bytes left:
30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 77 51 1b f4 d7 17 d7 ad 8c 2d e5 89 2a ca e0 6d a3 c0 7d 13 4d d7 b8 01 14 87 03 00 69 e4 9b b3
I would like two things about this:
Is it possible to determine the hash function used? Encoded algorithm ID should be prepended to the actual body of the digest, is it possible to tell what algorithm it is from the raw bytes?
Where does the actual digest start (how long the head / digest is)?
This appears to be EMSA-PKCS1-v1_5 as described in RFC 3447, which means that after removing the header and padding, you have a DER encoding of an AlgorithmIdentifier followed by the hash value itself.
From the RFC:
For the six hash functions mentioned in Appendix B.1, the DER
encoding T of the DigestInfo value is equal to the following:
[...]
SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 || H.
So in your example, the hash value is the SHA-256 hash starting 77511bf4d7....
Related
I am trying to secure the Akka Management port of a Scala microservice with TLS by starting Akka Management programatically on port 8558 via AkkaManagement:withHttpsConnectionContext().
When the Scala service is run, it reads from the configuration and starts Akka Management fine, but does not appear to be operating with TLS encryption enabled.
~$ telnet localhost 8558
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /cluster/members HTTP/1.0
Host: 127.0.0.1
HTTP/1.1 200 OK
Server: akka-http/10.4.0
Date: Fri, 27 Jan 2023 20:26:00 GMT
Connection: close
Content-Type: application/json
Content-Length: 439
From what I can tell, Akka Management is serving HTTP from what should be the HTTPS port, and not encrypting the response.
:~$ openssl s_client -connect localhost:8558 -state -debug
CONNECTED(00000003)
SSL_connect:before SSL initialization
write to 0x56097b12c740 [0x56097b13ee80] (283 bytes => 283 (0x11B))
0000 - 16 03 01 01 16 01 00 01-12 03 03 05 27 1c 50 1b ............'.P.
0010 - e6 b6 23 5a e5 da d5 48-29 33 51 08 13 fb b6 aa ..#Z...H)3Q.....
0020 - 23 f4 2e 44 93 75 95 97-59 9a 1c 20 99 b0 36 06 #..D.u..Y.. ..6.
0030 - 1f 3d 79 d0 d8 e8 36 7e-41 5e 2e ff 70 f7 ce a5 .=y...6~A^..p...
0040 - 0a 5a 56 e4 a9 fc 15 09-d0 3c a7 9b 00 3e 13 02 .ZV......<...>..
0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa .....,.0........
0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27 .+./...$.(.k.#.'
0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d .g.....9.....3..
0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 8b ...=.<.5./......
0090 - 00 0b 00 04 03 00 01 02-00 0a 00 0c 00 0a 00 1d ................
00a0 - 00 17 00 1e 00 19 00 18-00 23 00 00 00 16 00 00 .........#......
00b0 - 00 17 00 00 00 0d 00 2a-00 28 04 03 05 03 06 03 .......*.(......
00c0 - 08 07 08 08 08 09 08 0a-08 0b 08 04 08 05 08 06 ................
00d0 - 04 01 05 01 06 01 03 03-03 01 03 02 04 02 05 02 ................
00e0 - 06 02 00 2b 00 05 04 03-04 03 03 00 2d 00 02 01 ...+........-...
00f0 - 01 00 33 00 26 00 24 00-1d 00 20 4e 63 c8 62 95 ..3.&.$... Nc.b.
0100 - f3 8e a4 b2 04 44 1a 83-6e 53 99 4b ef d0 f7 51 .....D..nS.K...Q
0110 - eb 95 b5 8c 1d 3c f7 f7-fa c1 1b .....<.....
SSL_connect:SSLv3/TLS write client hello
read from 0x56097b12c740 [0x56097b135c63] (5 bytes => 5 (0x5))
0000 - 48 54 54 50 2f HTTP/
SSL_connect:error in error
139911147234624:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 283 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
read from 0x56097b12c740 [0x56097b123f00] (8192 bytes => 189 (0xBD))
0000 - 31 2e 31 20 34 30 30 20-42 61 64 20 52 65 71 75 1.1 400 Bad Requ
0010 - 65 73 74 0d 0a 53 65 72-76 65 72 3a 20 61 6b 6b est..Server: akk
0020 - 61 2d 68 74 74 70 2f 31-30 2e 34 2e 30 0d 0a 44 a-http/10.4.0..D
0030 - 61 74 65 3a 20 46 72 69-2c 20 32 37 20 4a 61 6e ate: Fri, 27 Jan
0040 - 20 32 30 32 33 20 32 30-3a 33 36 3a 30 32 20 47 2023 20:36:02 G
0050 - 4d 54 0d 0a 43 6f 6e 6e-65 63 74 69 6f 6e 3a 20 MT..Connection:
0060 - 63 6c 6f 73 65 0d 0a 43-6f 6e 74 65 6e 74 2d 54 close..Content-T
0070 - 79 70 65 3a 20 74 65 78-74 2f 70 6c 61 69 6e 3b ype: text/plain;
0080 - 20 63 68 61 72 73 65 74-3d 55 54 46 2d 38 0d 0a charset=UTF-8..
0090 - 43 6f 6e 74 65 6e 74 2d-4c 65 6e 67 74 68 3a 20 Content-Length:
00a0 - 32 33 0d 0a 0d 0a 55 6e-73 75 70 70 6f 72 74 65 23....Unsupporte
00b0 - 64 20 48 54 54 50 20 6d-65 74 68 6f 64 d HTTP method
read from 0x56097b12c740 [0x56097b123f00] (8192 bytes => 0 (0x0))
It also looks like attempting to access Akka Management with TLS is also failing completely.
I'm seeing the following log message on the microservice when using the openssl command:
[WARN] [akka.actor.ActorSystemImpl] [] [inbound-transaction-akka.actor.default-dispatcher-65] [] [] [] [] - Illegal request, responding with status '400 Bad Request': Unsupported HTTP method: The HTTP method started with 0x16 rather than any known HTTP method from 192.168.96.1:39184. Perhaps this was an HTTPS request sent to an HTTP endpoint?
I tried starting Akka Management programatically with TLS encryption, and got unencrypted HTTP instead.
Here is the code used to setup HTTPS and start Akka Management:
def getHttpsConnectionContext(config: HttpsConfig): SSLContext = {
val keystore: KeyStore = KeyStore.getInstance("PKCS12")
val keystoreFile: InputStream =
getClass.getClassLoader.getResourceAsStream(config.keystoreFile)
val keystorePassword = config.keystorePassword.toCharArray
keystore.load(keystoreFile, keystorePassword)
val keyManagerFactory: KeyManagerFactory =
KeyManagerFactory.getInstance("SunX509")
keyManagerFactory.init(keystore, keystorePassword)
val trustManagerFactory: TrustManagerFactory =
TrustManagerFactory.getInstance("SunX509")
trustManagerFactory.init(keystore)
val sslContext: SSLContext = SSLContext.getInstance("TLS")
sslContext.init(
keyManagerFactory.getKeyManagers,
trustManagerFactory.getTrustManagers,
new SecureRandom
)
sslContext
}
val httpsConfig: HttpsConfig =
HttpsConfig(
actorSystem.settings.config,
"akka.moo.https"
) match {
case Some(value) => value
case None => throw new ConfigurationException("Bad HTTPS config")
}
val sslContext: SSLContext =
HttpsContext.getHttpsConnectionContext(httpsConfig)
val httpsServer: HttpsConnectionContext =
ConnectionContext.httpsServer(sslContext)
val management = AkkaManagement(actorSystem)
management.start(_.withHttpsConnectionContext(httpsServer))
I'm not sure what the problem here is.
Thank you ahead of time for your help.
All values are in hexadecimal number system. On Pentium in protected mode, registers have the following value: LDTR = 06000000, GDTR = 08000000, CR3 = 10000000, DS = 14, CS = 0034 CR0 = 00000001.
If the instruction (e.g. MOV AL, [2A66] accesses the logical address 2A66, what physical address does it access? At what address is the segment descriptor located? Current memory status, looking at absolute addresses is:
........
06000000 CD 20 FF 9F 00 9A EE FE 1D F0 4F 03 22 05 8A 03
06000010 22 05 17 03 22 93 0D 04 01 01 01 00 02 FF FF FF
.........
08000000 CA 20 FF 9F 00 9A E3 FE 1D F2 4F 08 23 05 8A 07
08000010 26 05 19 03 22 05 0D 04 01 02 01 00 02 FF FA FF
.........
10000020 3A 56 21 40 2A 38 42 18 2A 56 42 40 8E 48 42 18
10000030 2A 36 42 40 9A 48 42 18 7A 56 42 20 8E 48 42 18
10000040 23 60 42 40 4E A8 42 18 5A 56 42 40 8E 48 42 18
.........
40426860 C6 06 23 99 00 80 3E 1D 96 00 74 03 E9 99 00 E8
40426870 A6 01 E8 FF 03 75 19 80 3E C4 98 00 34 00 AD 0A
40426880 13 96 00 BA E9 89 75 03 E9 17 01 C6 06 1F 99 01
40426890 B8 00 6C BE 08 98 BB 21
.........
C6011D70 C6 06 23 99 00 80 3E 1D 96 00 74 03 E9 99 00 E8
C6011D80 A6 01 E8 FF 03 75 19 80 3E C4 98 00 34 00 AD 0A
C6011D90 13 96 00 BA E9 89 75 03 E9 17 01 C6 06 1F 99 01
Could you give me some guidelines what is the problem here and what I need to know to solve it? Operating systems and registry is new to me, so I don't know what I'm supposed to do here. I don't know even where should I start.
I am trying to use mitmproxy to look at the traffic from my win32 schannel tls client. But when I try to use mitmproxy the following messages throw an "Bad HTTP request line" error with a leading 0 in the binary dump that does not exsist in the data that my client sends (I have checked with a little python server).
"CONNECT www.example.com:443 HTTP/1.0\r\n\r\n"
"HTTP/1.0 200 Connection established\r\n\r\n"
Send Tls Client Hello:
16 03 03 00 AC 01 00 00 A8 03 03 5F 80 1A 2D F6 2A 59 DE 18
69 F0 BB 3C 2D 2B 11 90 F8 8C A7 F9 D7 96 CD DC 32 88 02 22
11 90 6A 00 00 2A C0 2C C0 2B C0 30 C0 2F 00 9F 00 9E C0 24
C0 23 C0 28 C0 27 C0 0A C0 09 C0 14 C0 13 00 9D 00 9C 00 3D
00 3C 00 35 00 2F 00 0A 01 00 00 55 00 00 00 14 00 12 00 00
0F 77 77 77 2E 65 78 61 6D 70 6C 65 2E 63 6F 6D 00 0A 00 08
00 06 00 1D 00 17 00 18 00 0B 00 02 01 00 00 0D 00 1A 00 18
08 04 08 05 08 06 04 01 05 01 02 01 04 03 05 03 02 03 02 02
06 01 06 03 00 23 00 00 00 17 00 00 FF 01 00 01 00
Bad HTTP request line: b"\x00\x16\x03\x03\x00\xac\x01\x00\x00\xa8\x03\x03_\x80\x17\xbd\x1f\xf3\x8fO\xddy\xfb\xaaR\x1c\xeb\xe0sdD\xb7}|\xeb\xbes\xdf$3\xb6\xd9\ry\x00\x00*\xc0,\xc0+\xc00\xc0/\x00\x9f\x00\x9e\xc0$\xc0#\xc0(\xc0'\xc0"
Now my question: Is this just a lack of understanding in how proxys and tls work or an error from mitmproxy?
I'm using Akka Streams to create a TCP server using akka.stream.scaladsl.TLS with client certificate authentication. I'm working on creating an echo server as a first proof of concept.
In the meantime, I'm new to Scala/Akka/Akka Streams and so I created a similar server and TCP client in Python to provide tooling in testing my work in Scala. The Python server/client are functional using client cert authentication. When connecting to the server, the client takes the following steps:
Creates and configures an SSLContext
Creates a socket using socket.create_connection()
Wraps the socket with the SSLContext using SSLContext.wrap_socket(). This creates the peer connection
Once connected, prints the server certificate
Infinite loop asking for input and sending each input to the server
I believe I have the server completed using Akka Streams and akka.stream.scaladsl.TLS, but when I attempt to connect using my Python client the client never gets past connecting to the peer using context.wrap_socket(sock, server_hostname=host). The server successfully binds the TCP connection and creates the corresponding IncomingConnection object. The client/server also never timeout (the client just sits awaiting the handshake?).
My biggest problem is that I see no information from my TLS BidiFlow, akka.stream.scaladsl.TLS. I have no idea what step in the handshake I'm stuck at, which makes troubleshooting very difficult.
Is there any way to output some information throughout the TLS handshake process? It seems as though all of the functionality is encapsulated and I don't know if there's any way to troubleshoot.
Otherwise, I'm attempting to troubleshoot with openssl and get the following:
bash$ openssl s_client -connect myserver.com:443 -state -debug
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x7fd914100080 [0x7fd915001000] (318 bytes => 318 (0x13E))
0000 - 16 03 01 01 39 01 00 01-35 03 03 e3 ff 5d fb 26 ....9...5....].&
0010 - 15 e3 32 89 37 e2 cb 95-f5 00 bd df 13 3d ae a6 ..2.7........=..
0020 - d7 37 db 4e 80 19 63 ad-d6 6c f1 00 00 98 cc 14 .7.N..c..l......
0030 - cc 13 cc 15 c0 30 c0 2c-c0 28 c0 24 c0 14 c0 0a .....0.,.(.$....
0040 - 00 a3 00 9f 00 6b 00 6a-00 39 00 38 ff 85 00 c4 .....k.j.9.8....
0050 - 00 c3 00 88 00 87 00 81-c0 32 c0 2e c0 2a c0 26 .........2...*.&
0060 - c0 0f c0 05 00 9d 00 3d-00 35 00 c0 00 84 c0 2f .......=.5...../
0070 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.........g
0080 - 00 40 00 33 00 32 00 be-00 bd 00 45 00 44 c0 31 .#.3.2.....E.D.1
0090 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%.......<./
00a0 - 00 ba 00 41 c0 11 c0 07-c0 0c c0 02 00 05 00 04 ...A............
00b0 - c0 12 c0 08 00 16 00 13-c0 0d c0 03 00 0a 00 15 ................
00c0 - 00 12 00 09 00 ff 01 00-00 74 00 0b 00 04 03 00 .........t......
00d0 - 01 02 00 0a 00 3a 00 38-00 0e 00 0d 00 19 00 1c .....:.8........
00e0 - 00 0b 00 0c 00 1b 00 18-00 09 00 0a 00 1a 00 16 ................
00f0 - 00 17 00 08 00 06 00 07-00 14 00 15 00 04 00 05 ................
0100 - 00 12 00 13 00 01 00 02-00 03 00 0f 00 10 00 11 ................
0110 - 00 23 00 00 00 0d 00 26-00 24 06 01 06 02 06 03 .#.....&.$......
0120 - ef ef 05 01 05 02 05 03-04 01 04 02 04 03 ee ee ................
0130 - ed ed 03 01 03 02 03 03-02 01 02 02 02 03 ..............
SSL_connect:unknown state
At which point openssl just hangs.
The Akka TLS support uses the built in Java TLS support behind the scenes, so to get debug output for TLS you'll have to enable debugging for that. It can be done through passing a system property to the JVM when starting it like so -Djavax.net.debug=all
Ultimately I found that the ssl-config logging is very sparse and wasn't helpful to resolving my issue. It does provide some debugging information but not much. Much better for debugging the TLS handshake is to use the -Djavax.net.debug=all flag when running the JVM. However, even this provides mixed results. For example, the resulting error I received is that the server couldn't find a matching cipher suite. Eventually I resolved my issue by realizing that when creating the input streams for my keystore/truststore I was specifying my path incorrectly.
Note for anyone coming across this: if you specify your keystore and truststore incorrectly the resulting input streams will be null and SSLContext.init will happily use these and provide an error that is unrelated to the keystore/truststore! This was very difficult to troubleshoot due to the incorrect error handling in SSLContext.
1)I am generating a Key file and a CSR with the help of openssl commands.
When displaying the CSR information with command “ openssl req -in test_csr.pem -noout –text” I get the following printings:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=GB, O=Test
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:a6:af:51:e9:23:65:50:27:14:83:f5:c8:11:10:
b1:03:0b:c7:0d:2d:ae:09:81:d9:f8:31:ad:8e:d7:
8e:65:a8:e0:d4:b4:7e:f9:3e:99:fa:b0:43:5d:e0:
41:7a:ee:9f:90:3d:05:c0:6f:80:bb:bb:9e:dd:64:
1e:15:89:0c:bc:e6:3d:76:4e:d0:ef:5c:e4:de:34:
00:d0:ac:5c:e4:f8:73:b7:22:12:81:30:28:85:cd:
5a:bb:d6:28:c3:dc:01:67:f5:56:3a:3f:01:f3:d7:
8f:d9:19:67:90:1e:23:24:b0:58:e9:80:44:c9:36:
ae:2b:c3:81:a3:ce:de:af:8b:32:33:7d:f7:81:d7:
80:b8:d2:97:ce:8b:f3:21:2b:e8:e2:96:d0:b1:3f:
cc:dc:18:18:c1:e7:99:81:2a:e9:45:20:b7:80:39:
b3:5d:b3:ab:61:6a:61:f3:e1:7c:32:b7:a8:29:1a:
b2:e1:02:81:42:1f:b4:c3:7f:bf:21:f6:2d:4f:ec:
19:d4:3a:d4:bf:90:8a:3b:f0:24:cf:83:1b:21:ab:
b2:cb:15:38:f2:ac:1d:80:ba:33:2b:c8:f4:8d:52:
90:7a:25:2b:e5:08:68:a2:f2:84:61:2f:24:48:a9:
25:97:85:28:64:52:f9:15:91:eb:36:c6:d9:98:08:
09:d3
Exponent: 65537 (0x10001)
Attributes:
a0:00
Now when I edit the key file in DER format with an Hex editor, I get the following data
30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01 00 A6 AF 51 E9 23 65 50 27 14 83 F5 C8 11 10 B1 03 0B C7 0D 2D AE 09 81 D9 F8 31 AD 8E D7 8E 65 A8 E0 D4 B4 7E F9 3E 99 FA B0 43 5D E0 41 7A EE 9F 90 3D 05 C0 6F 80 BB BB 9E DD 64 1E 15 89 0C BC E6 3D 76 4E D0 EF 5C E4 DE 34 00 D0 AC 5C E4 F8 73 B7 22 12 81 30 28 85 CD 5A BB D6 28 C3 DC 01 67 F5 56 3A 3F 01 F3 D7 8F D9 19 67 90 1E 23 24 B0 58 E9 80 44 C9 36 AE 2B C3 81 A3 CE DE AF 8B 32 33 7D F7 81 D7 80 B8 D2 97 CE 8B F3 21 2B E8 E2 96 D0 B1 3F CC DC 18 18 C1 E7 99 81 2A E9 45 20 B7 80 39 B3 5D B3 AB 61 6A 61 F3 E1 7C 32 B7 A8 29 1A B2 E1 02 81 42 1F B4 C3 7F BF 21 F6 2D 4F EC 19 D4 3A D4 BF 90 8A 3B F0 24 CF 83 1B 21 AB B2 CB 15 38 F2 AC 1D 80 BA 33 2B C8 F4 8D 52 90 7A 25 2B E5 08 68 A2 F2 84 61 2F 24 48 A9 25 97 85 28 64 52 F9 15 91 EB 36 C6 D9 98 08 09 D3 02 03 01 00 01
I observe that in addition to the Key (from byte 33) as is it displayed in the previous step, there is extra data before the key (32 first bytes) and after the key (5 last bytes).
Does somebody know where the extra information comes from and how to decrypt it?
2)I have to test a configuration where the pair of the Keys (private and public) and the hash signature are generated in a smart card with the help of vendor API’s. With a first API I get the Public Key and Length from the smart card. With a second API I a get the hash signature data and length.
I guess that the Public key can be inserted in the CSR with openssl X509_REQ_set_pubkey API (is it correct?).
The question is: Is there an existing openssl API I can use to insert the hash signature in the CSR (something like X509_REQ_sign but without hashing and signature process that has already been done by the smart card).
Thanks.
P.L.
First 256 bytes should be structure describing certificates owner (Subject, algorithm, etc).
Last 5 bytes is the RSA public exponent - 65537 in ASN.1 encoding.
To get more information use ASN.1 decoder (or openssl asn1parse command).
Unfortunately I don't know about such function on OpenSSL and don't have time to dig into their sources, but at least it is possible to form CSR ASN.1 structure manually, that's not that hard.