I'm trying to extract an ECDSA public key from my known_hosts file that ssh uses to verify a host. I have one below as an example.
This is the entry for "127.0.0.1 ecdsa-sha2-nistp256" in my known_hosts file:
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBF3QCzKPRluwunLRHaFVEZNGCPD/rT13yFjKiCesA1qoU3rEp9syhnJgTbaJgK70OjoT71fDGkwwcnCZuJQPFfo=
I ran it through a Base64 decoder to get this:
���ecdsa-sha2-nistp256���nistp256���A]2F[rUF=wXʈ'ZSzħ2r`M::WL0rp
So I'm assuming those question marks are some kind of separator (no, those are lengths). I figured that nistp256 is the elliptical curve used, but what exactly is that last value?
From what I've been reading, the public key for ECDSA has a pair of values, x and y, which represent a point on the curve. Is there some way to extract x and y from there?
I'm trying to convert it into a Java public key object, but I need x and y in order to do so.
Not all of characters are shown since they are binary. Write the Base64-decoded value to the file and open it in a hex editor.
The public key for a P256 curve should be a 65-byte array, starting from the byte with value 4 (which means a non-compressed point). The next 32 bytes would be the x value, and the next 32 the y value.
Here is the result in hexadecimal:
Signature algorithm:
00 00 00 13
65 63 64 73 61 2d 73 68 61 32 2d 6e 69 73 74 70 32 35 36
(ecdsa-sha2-nistp256)
Name of domain parameters:
00 00 00 08
6e 69 73 74 70 32 35 36
(nistp256)
Public key value:
00 00 00 41
04
5d d0 0b 32 8f 46 5b b0 ba 72 d1 1d a1 55 11 93 46 08 f0 ff ad 3d 77 c8 58 ca 88 27 ac 03 5a a8
53 7a c4 a7 db 32 86 72 60 4d b6 89 80 ae f4 3a 3a 13 ef 57 c3 1a 4c 30 72 70 99 b8 94 0f 15 fa
So you first have the name of the digital signature algorithm to use, then the name of the curve and then the public component of the key, represented by an uncompressed EC point. Uncompressed points start with 04, then the X coordinate (same size as the key size) and then the Y coordinate.
As you can see, all field values are preceded by four bytes indicating the size of the field. All values and fields are using big-endian notation.
Related
Currently, I am attempting to generating a hash of a user password for PDF, given the encrypted PDF file and the plain password. I follow the instruction of this article. However, the hash I've computed is different from the hash stored in the PDF file.
The hashed user password (/U entry) is simply the 32-byte padding
string above, encrypted with RC4, using the 5-byte file key. Compliant
PDF viewers will check the password given by the user (by attempting
to decrypt the /U entry using the file key, and comparing it against
the padding string) and allow or refuse certain operations based on
the permission settings.
First, I padded my password "123456" using a hardcoded 32-byte string, which gives me
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
I tried to compute the hash with RC4 using the 5-byte file key as the key. According to the article:
The encryption key is generated as follows:
1. Pad the user password out to 32 bytes, using a hardcoded
32-byte string:
28 BF 4E 5E 4E 75 8A 41 64 00 4E 56 FF FA 01 08
2E 2E 00 B6 D0 68 3E 80 2F 0C A9 FE 64 53 69 7A
If the user password is null, just use the entire padding
string. (I.e., concatenate the user password and the padding
string and take the first 32 bytes.)
2. Append the hashed owner password (the /O entry above).
3. Append the permissions (the /P entry), treated as a four-byte
integer, LSB first.
4. Append the file identifier (the /ID entry from the trailer
dictionary). This is an arbitrary string of bytes; Adobe
recommends that it be generated by MD5 hashing various pieces
of information about the document.
5. MD5 hash this string; the first 5 bytes of output are the
encryption key. (This is a 40-bit key, presumably to meet US
export regulations.)
I appended the hashed owner key to the padded password, which gives me
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
C4 31 FA B9 CC 5E F7 B5 9C 24 4B 61 B7 45 F7 1A
C5 BA 42 7B 1B 91 02 DA 46 8E 77 12 7F 1E 69 D6
Then, I appended the /P entry (-4), treated as a four-byte integer, encoded with little endian, which gives me
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
C4 31 FA B9 CC 5E F7 B5 9C 24 4B 61 B7 45 F7 1A
C5 BA 42 7B 1B 91 02 DA 46 8E 77 12 7F 1E 69 D6
FC FF FF FF
Last, I appended the file identifier to it. The trailer of my PDF is:
trailer
<<
/Size 13
/Root 2 0 R
/Encrypt 1 0 R
/Info 4 0 R
/ID [<B5185D941CC0EA39ACA809F661EF36D4> <393BE725532F9158DC9E6E8EA97CFBF0>]
>>
and the result is
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
C4 31 FA B9 CC 5E F7 B5 9C 24 4B 61 B7 45 F7 1A
C5 BA 42 7B 1B 91 02 DA 46 8E 77 12 7F 1E 69 D6
FC FF FF FF B5 18 5D 94 1C C0 EA 39 AC A8 09 F6
61 EF 36 D4 39 3B E7 25 53 2F 91 58 DC 9E 6E 8E
A9 7C FB F0
MD5 hashing this block of data returns 942c5e7b2020ce57ce4408f531a65019. I RC4-ed the padded password with cryptii using the first 5 bytes of the MD5 hash as the key. However, it returns
90 e2 b5 21 2a 7d 53 05 70 d9 5d 26 95 c7 c2 05
6e 2a 28 40 63 e7 4a d4 e9 05 86 71 43 d1 39 d6
while the hash in PDF is
58 81 CA 74 65 DC 2E A7 5D D2 39 D4 43 9C 0D DE
28 BF 4E 5E 4E 75 8A 41 64 00 4E 56 FF FA 01 08
Which step am I doing wrong? I suspect that the problem happens because
I am appending the File Idenifier in a wrong format
I am using the wrong drop bytes with RC4.
The hash function is not for PDF 1.6
I make some mistake during those process
Or maybe the article is actually wrong
Files: Original PDF dummy.pdf, dummy-protected.pdf (Password: 123456)
Please help
There are two issues in your calculation:
The article to use refers to PDF encryption algorithms available for PDF-1.3 but your document is encrypted using an algorithm introduced with PDF-1.5.
You make an error when appending the file identifier - actually only the first entry of the ID array shall be appended, not both (which is not really clear from the article you use).
In a comment you asked accordingly
where can I find the password hashing detail for >V1.3 PDF?
I would propose using the PDF specification, ISO 32000.
As ISO specifications go, they are not free, but Adobe used to provide a version of ISO 32000-1 with merely the ISO header removed on their web site. Some days ago it has been removed (By design? By error? I don't know yet.) but you still find copies of it googl'ing for "PDF32000".
The relevant section in ISO 32000-1 is 7.6 Encryption and in particular 7.6.3 Standard Security Handler.
Following that information you should be able to correctly calculate the value in question.
(Alternatively you can also use old Adobe PDF references, the editions for PDF 1.5, 1.6, and 1.7 should also give you the information required for decrypting your document. But these references have been characterized as not normative in nature by prominent Adobe employees, so I would go for the ISO norm.)
Beware, though: After ISO 32000-1 had been published, Adobe introduced an AES-256 encryption scheme as an extension which obviously is not included in ISO 32000-1. You can find a specification in "Adobe Supplement to ISO 32000, base version 1.7, extension level 3".
Furthermore, with ISO 32000-2 that Adobe AES-256 encryption scheme and all older schemes became deprecated, the only encryption scheme to use with PDF-2.0 is a new AES-256 encryption scheme described in ISO 32000-2 which is based on the Adobe scheme but introduces some extra hashing iterations.
An Avro file contains the schema in plain text followed by the data in binary format. I'd like to know whether the schema (or some part of it) also exists in the binary part? I got a hunch that the schema (or just the field names) also get coded in the binary part because when I make some changes in the plain schema part of an AVRO file I get an error message when exporting the schema using the Avro-tool.jar .
When the binary encoding is used, the whole file is using a binary format.
The file starts with a 4 bytes header, then a map containing some metadata immediately follows. This map contains a "avro.schema" entry. The value of this entry is the schema stored as a string. After the map you will find your data.
If you edit the schema manually, read change its size, then length prefix stored just before this string will be incoherent and the file is corrupted.
See Binary encoding specification to learn how various types are binary encoded.
I'm not sure what you are trying to achieve, and I quite sure that is should not be done. But for fun, lets try to edit the schema in place.
For this example I will use the weather.avro file from the avro's source tree:
$ java -jar avro-tools-1.8.0.jar getmeta weather-orig.avro
avro.codec null
avro.schema {"type":"record","name":"Weather","namespace":"test","fields":[{"name":"station","type":"string"},{"name":"time","type":"long"},{"name":"temp","type":"int"}],"doc":"A weather reading."}
$ java -jar avro-tools-1.8.0.jar getschema weather-orig.avro
{
"type" : "record", "name" : "Weather", "namespace" : "test", "doc" : "A weather reading.",
"fields" : [
{"name" : "station", "type" : "string"},
{"name" : "time", "type" : "long"},
{"name" : "temp", "type" : "int"}
]
}
$ java -jar /avro-tools-1.8.0.jar tojson weather-orig.avro
{"station":"011990-99999","time":-619524000000,"temp":0}
{"station":"011990-99999","time":-619506000000,"temp":22}
{"station":"011990-99999","time":-619484400000,"temp":-11}
{"station":"012650-99999","time":-655531200000,"temp":111}
{"station":"012650-99999","time":-655509600000,"temp":78}
OK. This is our source file. Plain simple, two metadata entries and the schema defines three fields. Now, we will try to understand how things are stored in binary and how we can edit the file to change the rename station int station-id.
$ hexdump weather-orig.avro -n 256 -C
00000000 4f 62 6a 01 04 14 61 76 72 6f 2e 63 6f 64 65 63 |Obj...avro.codec|
00000010 08 6e 75 6c 6c 16 61 76 72 6f 2e 73 63 68 65 6d |.null.avro.schem|
00000020 61 f2 02 7b 22 74 79 70 65 22 3a 22 72 65 63 6f |a..{"type":"reco|
00000030 72 64 22 2c 22 6e 61 6d 65 22 3a 22 57 65 61 74 |rd","name":"Weat|
00000040 68 65 72 22 2c 22 6e 61 6d 65 73 70 61 63 65 22 |her","namespace"|
00000050 3a 22 74 65 73 74 22 2c 22 66 69 65 6c 64 73 22 |:"test","fields"|
00000060 3a 5b 7b 22 6e 61 6d 65 22 3a 22 73 74 61 74 69 |:[{"name":"stati|
00000070 6f 6e 22 2c 22 74 79 70 65 22 3a 22 73 74 72 69 |on","type":"stri|
00000080 6e 67 22 7d 2c 7b 22 6e 61 6d 65 22 3a 22 74 69 |ng"},{"name":"ti|
00000090 6d 65 22 2c 22 74 79 70 65 22 3a 22 6c 6f 6e 67 |me","type":"long|
000000a0 22 7d 2c 7b 22 6e 61 6d 65 22 3a 22 74 65 6d 70 |"},{"name":"temp|
000000b0 22 2c 22 74 79 70 65 22 3a 22 69 6e 74 22 7d 5d |","type":"int"}]|
000000c0 2c 22 64 6f 63 22 3a 22 41 20 77 65 61 74 68 65 |,"doc":"A weathe|
000000d0 72 20 72 65 61 64 69 6e 67 2e 22 7d 00 b0 81 b3 |r reading."}....|
000000e0 c4 0a 0c f6 62 fa c9 38 fd 7e 52 00 a7 0a cc 01 |....b..8.~R.....|
000000f0 18 30 31 31 39 39 30 2d 39 39 39 39 39 ff a3 90 |.011990-99999...|
First four bytes, 4f 62 6a 01, are the header
The next thing is a long describing the size of the first block of the "metadata" map. long are encoded using variable-length zig-zag coding, so here 04 means 2 which coherent with the output of getmeta. (remember to read the Avro specification to know how various data type are encoded)
Just after you will find the first key of the map. A key is a string and a string is prefixed by its length in bytes. Here 0x14 means 10 bytes which is the length of "avro.codec" when encoded in UTF-8.
You can then skip the next 10 bytes and go to the next element. Etc. You can advance until you spot the avro.schema part.
Just after this string is the length of the map value (which is a string since it is our schema). That is what you want to modify. We are renaming station into station-id so you want to add 3 to the current length, so f2 02 should now be f8 02 (remember variable length zig zag coding ?).
You can now update the schema string to add "-id"
Enjoy
java -jar /home/cmathieu/Sources/avro-trunk/lang/java/tools/target/avro-tools-1.8.0-SNAPSHOT.jar tojson weather.avro
{"station-id":"011990-99999","time":-619524000000,"temp":0}
{"station-id":"011990-99999","time":-619506000000,"temp":22}
{"station-id":"011990-99999","time":-619484400000,"temp":-11}
{"station-id":"012650-99999","time":-655531200000,"temp":111}
{"station-id":"012650-99999","time":-655509600000,"temp":78}
But as I said, you most likely don't want to do that.
I have two queue manager servers running on two boxes. QM1 has a sender channel defined , and QM2 has a receiver channel with the same name.
I have created self signed certificate for each QM , extracted and added the public part of each certificate to the other QM's key db. Altered each channel to use CipherSpec TRIPLE_DES_SHA_US.
This setup works perfectly fine, if QM names don't contain any special character. If name of the sender QM is A_QM and the other one is B_QM , the sender channel never comes up and is in RETRYING state.
while creating self-signed certificate I am using label ibmwebspheremqa_qm
in case of A_QM and ibmwebspheremqqm1 when the queue manager is QM1. Similarly when adding the public part of the certificate I am preserving the other QM's label. This is the only difference in the whole setup.
Is there any restriction in defining QM names if I want to configure SSL or TLS ?
I had no trouble creating a pair of QMgrs and channels as described and getting them to run:
[mqm#rhel6base scripts]$ runmqsc A_QM
5724-H72 (C) Copyright IBM Corp. 1994, 2014.
Starting MQSC for queue manager A_QM.
dis chs(*) all
1 : dis chs(*) all
AMQ8417: Display Channel Status details.
CHANNEL(A_QM.B_QM) CHLTYPE(SDR)
BATCHES(0) BATCHSZ(50)
BUFSRCVD(1) BUFSSENT(1)
BYTSRCVD(268) BYTSSENT(268)
CHSTADA(2015-04-01) CHSTATI(10.57.43)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(127.0.0.1(3115)) CURLUWID(0C031C5501020010)
CURMSGS(0) CURRENT
CURSEQNO(0) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(0000130700000001) LOCLADDR(127.0.0.1(53145))
LONGRTS(999999999) LSTLUWID(0000000000000000)
LSTMSGDA( ) LSTMSGTI( )
LSTSEQNO(0) MCASTAT(RUNNING)
MONCHL(OFF) MSGS(0)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME(B_QM) SHORTRTS(10)
SSLCERTI(CN=rhel6base.ioptconsulting.com)
SSLKEYDA( ) SSLKEYTI( )
SSLPEER(SERIALNUMBER=55:1C:06:B2,CN=rhel6base.ioptconsulting.com)
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(MQGET)
XBATCHSZ(0,0) XMITQ(B_QM)
XQTIME(0,0) RVERSION(08000001)
RPRODUCT(MQMM)
[mqm#rhel6base ssl]$ runmqakm -cert -list -db key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! ibmwebspheremqb_qm
*- ibmwebspheremqa_qm
[mqm#rhel6base ssl]$ runmqakm -cert -list -db ../../B_QM/ssl/key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! ibmwebspheremq_a_qm
*- ibmwebspheremqb_qm
[mqm#rhel6base ssl]$
REFRESH SECURITY TYPE(SSL)
The most likely cause for the behavior you are seeing is not issuing refresh security or restarting the QMgrs after updating their keystores. For example:
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc A_QM
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc B_QM
or
endmqm -i A_QM; strmqm A_QM
endmqm -i B_QM; strmqm B_QM
One aspect of security for the keystore is that there is only ever one version of it in memory at a time. If it were possible for one channel to have one version and another channel to have another version, it would become impossible to determine which was the "right" one in order to detect tampering. So when the KDB is updated, the refresh security command causes the QMgr to stop all running TLS channels, dump the KDB from memory, and reload the KDB when one of the channels starts.
(MQ doesn't use SSL, by the way, never has. It uses TLS with SSL ciphers and now that SSL itself is broken, best to get used to saying TLS because that will help to remember to use TLS ciphers exclusively going forward.)
So after updating the KDB if you did not run the refresh, it is likely that the refresh was not done and the QMgr doesn't yet know about the newly added certificate for the remote QMgr.
When SSLCAUTH(OPTIONAL) is not optional
Another common problem with TLS is a misunderstanding of SSLCAUTH(OPTIONAL). Many people believe that this always results in one-way authentication so they set SSLCAUTH(OPTIONAL) and then exchange certs in only one direction. For example, QM1 has TLS channels to QM2 so obviously has its own personal certificate. Then we try to connect A_QM to it. We import A_QM's personal cert to QM1's KDB, refresh security everywhere, DEF CHL(A_QM.QM1) ... SSLCAUTH(OPTIONAL) on both sides and try to start the channel.
The misunderstanding is that if the thing initiating the channel has a personal cert it will send it in all cases. To test with SSLCAUTH(OPTIONAL) requires removing any personal cert from the keystore on the side initiating the connection. Often people do not realize this and spend many hours (in some cases weeks) struggling to understand why this fails.
For your purposes always exchange the personal certs in both directions.
Incomplete cert exchange
The other common problem working with self-signed certs is when a cert is generated multiple times with the same label and/or CN value and there's a mismatch between the personal cert on one end versus the public portion on the other. This is easily checked by viewing the cert details and checking that the fingerprint and other details match like so:
[mqm#rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
BF 16 1C 62
Fingerprint : MD5 :
90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
AuthorityKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
authorityIdentifier:
authorityCertSerialNumber:
SubjectKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
[mqm#rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db ../../B_QM/ssl/key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
BF 16 1C 62
Fingerprint : MD5 :
90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
AuthorityKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
authorityIdentifier:
authorityCertSerialNumber:
SubjectKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
Debugging
Check the error logs. In particular, it is good security design to give an attacker as little information as possible to always check the logs of the QMgr that is receiving the connection first. If it has detected the error it will have detailed logs and the sending side will have sparse logs like "the remote QMgr disconnected" which doesn't reveal much to an attacker.
If the error is actually on the sending side, then it will have most detailed error messages and the receiving side will have little or none. For example, if the sending side can't find its stash file the connection isn't ever attempted and the receiving side will have no record of the event.
Finally, there is always the possibility that you may discover a bug working with GSKit and MQ, or that you are trying to use features not relevant to version of MQ that you are working on. For this reason, it is always best to include a dspmqver -a in your question. If after all of this, you still can't get it to work, please update the question with the dspmqver -a output and the results of your further testing.
In summary
To sum up:
QMgr names like A_QM are perfectly valid.
First make sure that the QMgrs have picked up their new KDB files after changes by restarting the QMgrs or running REFRESH SECURITY TYPE(SSL).
Make sure to exchange certs in both directions every time.
Check the error logs on both sides starting with the side receiving the connection request.
Always include output from dspmqver -a when requesting help with GSKit, certs or TLS since the behavior varies by version and fix pack.
My application is using SSL over SMTP.
But I faced a problem of extra byte at the end.
The packet which I recieved is as follows: (Hex dump of SSL Record packet)
17 03 01 01 00 9A 07 74 E3 4B E0 07 17 71 38 BF 29 7E 70
E9 14 CC B1 97 77 4C B9 AB A0 9F 88 7B D4 ED 14 8E 97 F2
5A BE 46 56 D4 12 BC 15 01 49 EE CE A1 ED 3F D3 6E 7F AA
DC 6B DF 41 11 74 7B 55 B8 D3 3E 8D EF 96 52 B0 BD 50 35
09 E7 2A FF 0E 39 58 C7 91 99 95 22 6F B0 73 57 28 B4 EA
C6 28 4C DC 5C DA 6C 31 FB 63 71 7D 08 F0 DD 78 C4 08 C5
27 90 04 C7 09 59 E4 83 F4 4D 9A 7B 65 E9 AF 38 44 B4 CD
9E 4D BE 80 0D 07 24 8D C3 79 99 DC 02 81 D7 97 21 16 0B
28 44 82 ED E4 5F E6 91 81 A5 28 C1 C8 92 60 36 4E DE 27
AF D0 2B EE FB 9D 12 9C 2B 4F 3F 29 F2 04 8F DC 21 39 4F
80 23 7E 78 3C A0 29 E0 67 E7 9F 90 B6 1F D4 08 63 3E CE
73 E1 17 72 8D B1 8C 3D A8 59 C0 0F 03 59 7A A6 5D F9 7A
40 57 D6 8D 94 48 93 BF D8 17 C6 70 79 36 13 D0 F1 D1 D2
69 D4 05 9D 67 86 6D E9 66 D0 83 4A D8 5E 20
The length of this packet as seen from SSL 3.1 protocol is 256 Bytes.
But there is one extra byte at the end (shown in bold at the end).
Due to this extra byte at the end, when next packet is being read, then this 20 is also read and causes error of SSL_R_WRONG_VERSION_NUMBER (I am using OpenSSL Library for SSL).
Next packet which I recieved is like (as per packet sniffer)
17 03 01 00 18 ...
But when next read is being done, OpenSSL reads packet as 20 17 03 01 .. which causes the error (since 17 03 is wrong version for 03 01)
I would like to know if this (extra byte at the end) is a part of SSL standard.
Please suggest me how to handle this case in OpenSSL. OpenSSL version is 1.0.0.
No. The extra byte is not as a part of SSL Standard.
As per SSL Standard (RFC 2246 for TLS 1.0, Latest is RFC 5246 for TLS 1.2) the record of SSL is as below:
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
The fragment will be exactly of the length as specified by uint16 length member. So, the 20 must be getting inserted either incorrectly by the Server Implementation, or some other software in the middle is inserting it when the data is in network.
Openssl reads exactly the number of bytes as specified by uint16 length member which is why it doesn't read 20.
Some of the points which you can focus on are:
1. Does this happen with the first application data packet which is transferred immediately after handshake? (From the content type I assumed this packet dump is for application data)
2. Is this a random occurance? Do all connections with that particular server exhibit the same behavior?
3. You can try to get the dump of the packet sent at the Server to see if 20 is present when the packet is being sent at the Server side itself or it is getting added during it's flight.
4. Could there be a Firewall related problem? (I don't know about Firewall, so didn't give more details here)
Hope this helps!
I was bashing my head with this one today; finally resorted to this:
_sslStream.Write(merged, 0, merged.Length - 1)
Problem solved, move along!
http://www.faqs.org/rfcs/rfc4253.html
::http://www.faqs.org/rfcs/rfc4251.html
Does anyone know the SSH key file format?
!! UPDATE
!! The base64 function I was using doesn't work. After running the key file through a different function (mozilla's built in atob()) the data fit into the specifications listed above.
I have rsa key files created with puttygen, but I must be missing something critical. Here is the hex of the public section:
00 00 00 07 73 73 68 2d 72 73 61 00 00 00 01 25
00 00 00 10 1c 1c 57 3f 4f 58 63 69 38 ad 19 35
b5 28 3d 78 53 35 53 6c 15 0e 69 23 ac 17 14 84
21 29 13 07 36 62 90 26 37 93 73 17 28 b8 ce 95
c3 11 24 21 61 b7 82 d9 04 42 97 f8 27 c3 44 06
46 ca e8 a3 a3 34 d7 3c c3 95 13 dd 16 1b 2c 29
7c 35 19 5f c2 7a 17 d5 14 0d 26 36 27 18 71 67
8d 9c 5b c4 7d
first 4 bytes are UINT 7, the number of bytes inthe following string "ssh-rsa" but the format stops making sense after that. It SHOULD be followed by two MPINT but they lengths don't add up for the 3rd value.
Thanks!
It's in ASN.1 syntax. You should be able to use an ASN.1 parser along with the specs for the file contents to decipher it.