I encounter a hostname mismatch error at the client side in the server certificate verification step:- "Verify return code: 62 (hostname mismatch)".
But am able to see that hostname sent in Client-hello in SNI extension is matching with server-certificate's Subject name(Common Name):-
SNI extension in client-hello;-
extension_type=server_name(0), length=18
0000 - 00 10 00 00 0d 54 4c 53-2d 55 6e 69 74 2d 54 .....TLS-Unit-T
000f - 65 73 74 est
extension_type=ec_point_formats(11), length=4
Server-certificate common-name:-
Subject: C = IN, ST = KA, L = Bangalore, O = Cisco, CN = TLS-Unit-Test
Subject field is deprecated. Proper TLS clients do not look in this field at all, they examine SAN extension instead. SAN extension must contain all domain names the certificate is valid for.
Related
I need to decompress hex values and convert those to string.
Actual problem is that i'm not able to figure out how to decompress hex values
Hex do not contain any headers,
If i copy hex codes to CyberChef i'm able to decompress those and have original string
In CyberChef only Raw Inflate operation is needed
So i'm hoping help how to do raw inflate in R
I have tried memDecompress using all options without success (i.e gzip etc)
UPDATE:
Here is a sample from hex:
e3 0e 71 0d 0e f1 54 c8 cb 2f 52 30 02 00
which i'm able to convert using CyberChef to string
".TESTI nor 2"
RLdata<- sqlQuery(connection, ..... AS Varbinary(max) AS NOTEShort ......
> RLdata$NOTEshort[4268]
[[1]]
[1] e3 0e 71 0d 0e f1 54 c8 cb 2f 52 30 02 00
> unlist(RLdata$NOTEshort[4268])
[1] e3 0e 71 0d 0e f1 54 c8 cb 2f 52 30 02 00
> memDecompress(unlist(RLdata$NOTEshort[4268]),type = "gzip", asChar = TRUE)
Error in memDecompress(unlist(RLdata$NOTEshort[4268]), type = "gzip", :
internal error -3 in memDecompress(2)
> memDecompress(unlist(RLdata$NOTEshort[4268]),type = "unknown", asChar = TRUE)
[1] "ã\016q\r\016ñTÈË/R0\002"
Warning message:
In memDecompress(unlist(RLdata$NOTEshort[4268]), type = "unknown", :
unknown compression, assuming none
If you convert it into Base64 and then decode it back to Hex I think it decompresses to original, but may have been changed by a bug fix. It used to do this a couple of years back but I haven't used CyberChef in a while, sorry
Had to do this using python3. Zlib.decompress() did the trick.
Link to python solution
Read Dynamics NAV Table Metadata with SQL
I have an app connecting to an Azure AppServer thorugh WebServices (using SoapHttpClientProtocol).
It was working perfectly on .NET 3.5sp1, when i upgraded to .NET 4.6.1, it works ok on w10 boxes, but some w7 or w8 fail with:
The underlying connection was closed: An unexpected error occurred on a send
If I modify the constructor adding:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Ssl3;
it does works. But i want to use Tls1.2, instead of Ssl3. if i use
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
(or the default) it gives the error on the w7 and w8 boxes.
This is the list of ciphers presented to the server on the w10 (it works):
CONNECT spac-test.cloudapp.net:443 HTTP/1.1 Host:
spac-test.cloudapp.net Connection: Keep-Alive
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted
the parameters below.
Version: 3.3 (TLS/1.2) Random: 58 17 93 A5 5C 57 36 C2 97 69 48 B2 92
5C 93 44 86 1A 87 99 19 53 4D 04 C4 CB EE C0 87 70 30 67 "Time":
1/10/2058 1:26:48 AM SessionID: empty Extensions:
server_name xxx.cloudapp.net
elliptic_curves unknown [0x1D),
secp256r1 [0x17], secp384r1 [0x18] ec_point_formats uncompressed
[0x0]
signature_algs sha256_rsa, sha384_rsa, sha1_rsa, sha256_ecdsa,
sha384_ecdsa, sha1_ecdsa, sha1_dsa, sha512_rsa, sha512_ecdsa
SessionTicket empty
extended_master_secret empty
renegotiation_info 00
Ciphers:
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C030] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[C02F] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[009F] TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
[009E] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C028] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0039] TLS_DHE_RSA_WITH_AES_256_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[009D] TLS_RSA_WITH_AES_256_GCM_SHA384
[009C] TLS_RSA_WITH_AES_128_GCM_SHA256
[003D] TLS_RSA_WITH_AES_256_CBC_SHA256
[003C] TLS_RSA_WITH_AES_128_CBC_SHA256 [0035] TLS_RSA_AES_256_SHA
[002F] TLS_RSA_AES_128_SHA [000A] SSL_RSA_WITH_3DES_EDE_SHA
[006A] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
[0040] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
Compression: [00] NO_COMPRESSION
... and here is what is being presented on the PC which DOES NOT WORK:
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted
the parameters below.
Version: 3.3 (TLS/1.2) Random: 58 17 97 37 8C 71 81 A2 0F 25 5F BE 3F
D1 37 8D B8 4C 4F D3 58 BF A5 C6 EB DE E7 C3 6B 74 5D 86 "Time":>
Ciphers:
22/07/1999 9:06:32 SessionID: empty Extensions:
renegotiation_info 00
server_name xxxx.cloudapp.net
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
signature_algs sha256_rsa,
sha384_rsa, sha1_rsa, sha256_ecdsa, sha384_ecdsa, sha1_ecdsa, sha1_dsa
[003C] TLS_RSA_WITH_AES_128_CBC_SHA256
[002F] TLS_RSA_AES_128_SHA [003D] TLS_RSA_WITH_AES_256_CBC_SHA256
[0035] TLS_RSA_AES_256_SHA [0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0040] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[006A] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA [0004] SSL_RSA_WITH_RC4_128_MD5
Compression: [00] NO_COMPRESSION
I suppose has something to do with the ciphers been negotiated, but will like to make w7 use tls1.2 (I check options in IE show "use Tls1.2", also instaled the registry settings to enable tls 1.2 in w7 :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
any suggestions?
thanks
I trying to use Rs Digest package to create a signature for Amazon's API for Dynamodb. The signature requires sha256. Currently, I am testing R's digest package to see if its yield the correct output, given my input.
According to the Amazon website example, if my input is:
Input: "iam"
then my output should be:
Targeted Output: 'f72cfd46f26bc4643f06a11eabb6c0ba18780c19a8da0c31ace671265e3c87fa'
When I use the following R command:
digest("iam", algo="sha256", serialize=FALSE)
I get the following output:
"d457e3a99392a03f47057f50ac1cbc5d0365131575477971bf85177a0c0fed22"
I've tried various input combinations (setting serialize=TRUE, etc.) but have not had any luck.
Update
Per Rohit's response, I updated my R function and approach but I'm still not getting the correct Sample Signature. Here are my steps:
Based on Amazon Calculate AWS Signature Example
Now using the following R formula/script:
hmac(hmac(hmac(hmac("AWS4wJalrXUtnFEMI/K7MDENG+bPxRfiCYEXAMPLEKEY","20110909", "sha256", serialize=FALSE, raw=FALSE),"us-east-1", "sha256", serialize=FALSE, raw=FALSE),"iam", "sha256", serialize=FALSE, raw=FALSE),"aws4_request", "sha256", serialize=TRUE, raw=TRUE)
Getting this result:
fe bd 15 b6 ac 8d 68 7a 93 f9 1c 9c dc 9e f8 d9 f1 79 fb a8 62 71 14 98 3a 35 0c 09 a0 ea 2e f5
that does not match the Sample Signature in the Amazon example:
152 241 216 137 254 196 244 66 26 220 82 43 171 12 225 248 46 105 41 194 98 237 21 229 169 76 144 239 209 227 176 231
I tried changing parameters on my R function, but just can't seem to match the Amazon example. If anyone has some experience with this or seems something I'm doing wrong I'd appreciate your input. Thanks
I think there are two places where the problem lies.
Firstly, the AWS v4 Signature is an HMAC using the AWS secret key as a secret (among other things). The HMAC process uses a cryptographic hash like MD5 or SHA256, but it not just a hash of a single piece of data ("iam" in your case) - it also needs a 'secret'. I guess you would be more interested in the hmac function in R - it can use SHA256 as an 'algo'.
Secondly, if you look at the Java example of how a signature is calculated and the expected values:
static byte[] HmacSHA256(String data, byte[] key) throws Exception {
String algorithm="HmacSHA256";
Mac mac = Mac.getInstance(algorithm);
mac.init(new SecretKeySpec(key, algorithm));
return mac.doFinal(data.getBytes("UTF8"));
}
static byte[] getSignatureKey(String key, String dateStamp, String regionName, String serviceName) throws Exception {
byte[] kSecret = ("AWS4" + key).getBytes("UTF8");
byte[] kDate = HmacSHA256(dateStamp, kSecret);
byte[] kRegion = HmacSHA256(regionName, kDate);
byte[] kService = HmacSHA256(serviceName, kRegion);
byte[] kSigning = HmacSHA256("aws4_request", kService);
return kSigning;
}
Expected Values
kSecret = '41575334774a616c725855746e46454d492f4b374d44454e472b62507852666943594558414d504c454b4559'
kDate = '969fbb94feb542b71ede6f87fe4d5fa29c789342b0f407474670f0c2489e0a0d'
kRegion = '69daa0209cd9c5ff5c8ced464a696fd4252e981430b10e3d3fd8e2f197d7a70c'
kService = 'f72cfd46f26bc4643f06a11eabb6c0ba18780c19a8da0c31ace671265e3c87fa'
kSigning = 'f4780e2d9f65fa895f9c67b32ce1baf0b0d8a43505a000a1a9e090d414db404d'
You see that the kService is calculated using kRegion, which calculated using kDate, which itself is calculated using the AWS secret key. So you would have to do something similar to calculate the signature.
I'm trying to have a USIM perform call forwarding (a.k.a call redirection) using the proactive command SEND SS (TS 31.111 sections: 6.4.11, 8.14, etc.). Unfortunately I keep getting an error from the network which I can't understand.
I'm trying the following sequence:
ME->USIM: 8012000018 (FETCH from the ME toward UICC)
USIM->ME: 12 (procedure byte)
USIM->ME: D01681030411008202818305000909FFAA120A25556777B49000
D0 (proactive command) 16 (length)
81 (command details) 03 (length) 04 (command number) 11 (SEND SS) 00 (RFU)
82 (device identities) 02 (length) 81 (UICC) 83 (network)
05 (alpha identifier) 00 (length)
909FFAA120A25556777B4 (SS String = **21*0525576774#)
9000 (OK)
ME->USIM: 801400000D (Terminal response of size 0x0D)
USIM->ME: 14 (procedure byte)
ME->USIM: 81030411000202828103023424
81 (command details) 03 (length) 04 (command number) 11 (SEND SS) 00 (RFU)
02 (device identities) 02 (length) 82 (ME) 81 (UICC)
03 (Result) 02 (length) 34 (SS Return Error) 24 (???)
I can't figure out what '24' means.
Just to make sure I'm using a correct SS string, I activated CALL CONTROL on the USIM and dialed **21*0525576774# in the keypad. The result was as follows:
ME->UICC: 80C200001C (Envelope of length 0x1C)
UICC->ME: C2 (procedure byte)
ME->UICC: D41A020282810909FFAA120A25556777B4130924F51027D078CF0013
D4 (envelope) 1A (length)
02 (device identities) 02 (length) 82 (ME) 81 (UICC)
09 (send ss) 09 (length) FFAA120A25556777B4 (SS string)
13 (location information) 09 (length) 24F51027D078CF0013 (not relevant)
USIM->ME: 9000 (OK)
As you can see, the SS string is identical. When the ME sends it it seems to work (call forwarding is activated) yet when I try to send it from the UICC to the network I get the error '3424'.
I've searched through the specs (TS 31.111, TS 22.030 and even TS 24.080) but didn't find even the tiniest lead as to what I'm doing wrong.
Any help will be appreciated :)
Cheers,
Nir.
I think the problem occurs due to timer management(Action in contradiction with the current timer state) becouse
0x34-> Means SS Return Error
0x24-> Means Action in contradiction with the current timer state.
I am just beginner to ISO 8583 messaging format.
So, i already search information about that at WIKI and Code Project
So as i understand about that is..
this message we can divide 3 parts ...
1.MTI (Message Type Indicator)
1.1.Version
1.2.Message Class
1.3.Message Function
1.4.Message Origin
2.Bitmap
Indicate which data elements are present.
3.DataElement
The essence of the whole ISO message, contain information about the transaction such as ...
transaction type,
amount,
customerid
and so on.
So, After i reading these two web references, I want to make divide my ISO messaging log as MTI, bitmap, and Data Element.
For example.
(0800 2020000000800000 000000 000001 3239313130303031)
MTI: 0800 (1987 version, Network Management Message, Request, Acquirer)
Bitmap: 20 20 00 00 00 80 00 00 (eg. 20 = 0010 0000 ,so position 3 is on)
DataElement:(by seeing Bitmap , we can defined data element as follow)
field 03:000000 (Processing Code)
field 11:000001 (Systems trace audit number)
field 41:3239313130303031 (Card acceptor terminal idenfication)
But my problem is, I already have ISO 8583 messaging log from my ATM Machine.
This actual output messaging log is not very clear like this upper example.
So I cannot divide this message to MTI, Bitmap and Data element like upper example.
Here are my Example of data
00 14 5e 47 2e d8 00 1a d4 0c 32 0f 08 00 45 00
00 7b b2 ec 40 00 80 06 e5 29 ac 11 05 37 ac 11
05 0d 1a 78 1a 78 bf 1c 66 c8 8f 11 b5 a9 50 18
3f b6 c8 f6 00 00 00 51 31 31 1c 30 30 32 1c 1c
1c 31 3b 1c 3b 35 32 36 34 30 32 31 37 30 33 32
36 34 30 32 34 3d 31 34 30 35 32 32 31 31 30 30
What you have there as a sample is just the representation of the transaction info as it's transmitted over the wire. This is effectively the way all data transmission looks like at the transport layer, regardless of application.
Depending on the terminal management application/switch you're using (Postilion and Base24 are good examples), there should be a translation of that hex payload into ASCII text somewhere in your logs.
For the sample you have, you should first convert it to binary and then convert the binary result to ASCII. Using those steps, I can tell you the Institution Identifier Number (or Bank Identifier Number) in that sample is 526402. The snippet you've posted contains the Track 2 data, which also has the PAN in it. I'm not posting that here for obvious reasons (I'm not even going to apply the masking to it)
The hexadecimal dump for sure is not ISO 8583 dialect message. There are lot Field Separators with Hex code 0x1C.
The bytes at the beginning of your example looks like several layers of different packets. I do not pretend to correct decryption, but it might be Mobile IP packet inside IP packet inside TCP packet.
The last, most important part for your investigations - is the part of NDC Message - the Network message protocol from NCR for ATMs.
TCP - RFC 793
00 14 5e 47 2e d8 00 1a d4 0c 32 0f 08 00 45 00
00 7b b2 ec __ __ __ __ __ __ __ __ __ __ __ __
source_port: "0014" # // 20
destination_port: "5E47" # // 24135
sequence: "2ED8001A" # // 785907738
acknowledgment: "D40C320F" # // 3557569039
offset: "00" # [xxxx____]
bits: "00" # Control Bits
window: "4500" # // 17664
crc: "007B"
urgency: "B2EC" # // 45804
IP - RFC 791
__ __ __ __ __ __ 40 00 80 06 e5 29 ac 11 05 37 ac 11
05 0d 1a 78 1a 78 bf 1c __ __ __ __ __ __ __ __ __ __
b1:
version: "4"
IHL: "0" # Internet Header Length (in DWORDs)
type: # Type of Service
precedence: "00"
# 000_____ - Routine
delay: "00"
# ___0____ - Normal Delay
throughput: "00"
# ____0___ - Normal Throughput
relibility: "00"
# _____0__ - Normal Relibility
size: "8006" # // 32774
identifier: "E529"
fragment:
flags: "AC11"
# _0______________ - May Fragment
# __1_____________ - More Fragments
offset: "0C11" # [___xxxxxxxxxxxxx] // 3089
ttl: "05" # // 5
protocol: "37" # // 55 - MOBILE
crc: "AC11"
source_ip: "050D1A78" # // 5.13.26.120
destination_ip: "1A78BF1C" # // 26.120.191.28
Mobile IP (?) - RFC 3344
__ __ __ __ __ __ __ __ 66 c8 8f 11 b5 a9 50 18
3f b6 c8 f6 __ __ __ __ __ __ __ __ __ __ __ __
protocol: "66" # // 102 - PNNI
code: "C8" # // 200
crc: "8F11"
destination_ip: "B5A95018" # Home address // 181.169.80.24
source_ip: "3FB6C8F6" # Original sender // 63.182.200.246
Plus not identified part or already header from NDC message:
__ __ __ __ 00 00 00 51 __ __ __ __ __ __ __ __
NDC Transaction Request Message (beginning)
__ __ __ __ __ __ __ __ 31 31 1c 30 30 32 1c 1c
1c 31 3b 1c 3b 35 32 36 34 30 32 31 37 30 33 32
36 34 30 32 34 3d 31 34 30 35 32 32 31 31 30 30
a: "" # Protocol Header // skipped
b: "1" # Message Class
c: "1" # Message Sub-Class
FS: 0x1c
d: "002" # Logical Unit Number (LUNO)
FS: 0x1c
FS: 0x1c
e: // empty ?
FS: 0x1c
f: "1" # Top of Receipt Transaction Flag
g: ";" # Message Co-Ordination Number // 0x3b
FS: 0x1c
h: ";526402******4024=1405221100" # Track 2 Data // masked and expired
The rest part of NDC message in the next network packet / fragment.
#user3223324 I agree with #kolossus on many of his points including someones personal info appears in your trace. I can only hope it is a true test card.
This looks like a packet sniffer trace such as from Wireshark and not trace off of the terminal. Most ATM manufacturers have a trace mechanism right on the terminal itself that can be activated to capture Terminal to Host message and vice-versa but on newer machines requires escalated privilege or something in the possession of the field technician to activate with masking disabled. The host systems all also have a trace functionality that will at least turn it to text usually also accompanied by the hex for comparison. I believe Wireshark also has some basic HEX to Text conversion tools built into it.
The other problem I see you possibly encountering is that you are trying to decode something that you think is ISO-8583 but it is not. I know there are ISO-8583 ATMs out there, but they are few and far between as I believe most still run IFX, NDC, 911/912 or one of the other vendor specific formats or an emulation of them. Those are much shorter payload messages and there is little to no commonality between them and / or ISO-8583.
On variants of ISO-8583, there are many many variants that share the same primary, secondary, and some tertiary bitmaps. The specification itself allows for a lot of flexibility and customization and definition within certain criteria for many of the bitmaps, and then even the standard ones can have unique differences in the values they contain.
Most I see today are still a variant of ISO-8583-87 (Deluxe's is baseline of many) or a hybrid primarily supporting 01xx, 02xx, 04xx, and 08xx messages. I wouldn't get hung up on the first position too much as other than internally within applications (i.e. Postilion & Base24) it is almost always 0. Some are all text, some BCD with packed bitmaps, some text bitmaps with packed numerics.
The other thing you are going to have to account for is data element ByteMaps and now TLV as well.
So long answer, but we would need to know the format you are trying to parse or at least the make of the ATM.
To reverse a hex dump to a message can be very error prone.
ISO8583 protocol implementation varies based on the data it carries and the format of the individual fields. The field data can be BCD, ASCII etc and it may be fixed data or variable data that has a length indicator preceding the data to enable parsing.
If I look at your message closely, I see a lot of 0x1C's in it. These are generally field separators and it leads me to believe the message is a raw atm message in the atms specification and is not a traditional ISO8583 message.