I want Netty (Reactor Netty, to be specific) to set the Content-Length header in my requests. Currently, even when I send a request body in my request, the Content-Length header is not set. Is it possible to configure Netty to set this automatically (set it to 0 if there is no request body)? Postman does this.
Thanks!
I can answer this question for netty.... In netty this is not done automatically and the only way how to do it is to either set it your self or add a ChannelOutboundHandler that does it depending on the FullHttpMessage it receives.
It depends on the content that you want to send. If it is of type Mono, then we will calculate the content length and send a FullHttpMessage. If it is of type Flux, we will consider this as a chunked content and thus we will not calculate the content length.
Here is an example with Mono:
public static void main(String[] args) {
String response =
HttpClient.create()
.wiretap(true)
.post()
.uri("https://postman-echo.com/post")
.send(Mono.just(Unpooled.wrappedBuffer("something".getBytes(Charset.defaultCharset()))))
.responseContent()
.aggregate()
.asString()
.block();
System.out.println(response);
}
In the logs you should be able to see this:
17:01:46.813 [reactor-http-nio-4] DEBUG reactor.netty.http.client.HttpClient - [id: 0x668bd78f, L:/xxx:xxx - R:postman-echo.com/34.239.20.132:443] WRITE: 118B
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 50 4f 53 54 20 2f 70 6f 73 74 20 48 54 54 50 2f |POST /post HTTP/|
|00000010| 31 2e 31 0d 0a 75 73 65 72 2d 61 67 65 6e 74 3a |1.1..user-agent:|
|00000020| 20 52 65 61 63 74 6f 72 4e 65 74 74 79 2f 64 65 | ReactorNetty/de|
|00000030| 76 0d 0a 68 6f 73 74 3a 20 70 6f 73 74 6d 61 6e |v..host: postman|
|00000040| 2d 65 63 68 6f 2e 63 6f 6d 0d 0a 61 63 63 65 70 |-echo.com..accep|
|00000050| 74 3a 20 2a 2f 2a 0d 0a 63 6f 6e 74 65 6e 74 2d |t: */*..content-|
|00000060| 6c 65 6e 67 74 68 3a 20 39 0d 0a 0d 0a 73 6f 6d |length: 9....som|
|00000070| 65 74 68 69 6e 67 |ething |
+--------+-------------------------------------------------+----------------+
Related
This is a problem for us using vlingo-http backed by vlingo-wire, which was making direct use of Java NIO. We thought we were facing the infamous Netty Java NIO epoll bug that was fixed by Netty, so we applied Netty's fix to vlingo-wire. This didn't work. We finally gave up trying to solve it with direct NIO and even with incorporating Netty's fix. Thus, we switched to Netty in place of NIO, which works everywhere else, but not on Heroku.
Using Netty and some fine-grained logging we saw that for each request the server definitely replies. But for some reason the reply does not get past the Heroku router. For example:
2020-04-06T20:50:13.896574+00:00 app[web.1]: 20:50:13.896 [nioEventLoopGroup-3-4] DEBUG i.v.w.f.b.n.s.NettyInboundHandler - Request received
2020-04-06T20:50:13.896929+00:00 app[web.1]: 20:50:13.896 [nioEventLoopGroup-3-4] DEBUG i.n.handler.logging.LoggingHandler - [id: 0x1efddaa2, L:/172.18.27.14:59829 - R:/10.11.43.12:20716] READ COMPLETE
2020-04-06T20:50:13.897026+00:00 app[web.1]: Retrieving operations and...
2020-04-06T20:50:13.898394+00:00 app[web.1]: 20:50:13.898 [nioEventLoopGroup-3-4] DEBUG i.n.handler.logging.LoggingHandler - [id: 0x1efddaa2, L:/172.18.27.14:59829 - R:/10.11.43.12:20716] WRITE: 148B
2020-04-06T20:50:13.898395+00:00 app[web.1]: +-------------------------------------------------+
2020-04-06T20:50:13.898396+00:00 app[web.1]: | 0 1 2 3 4 5 6 7 8 9 a b c d e f |
2020-04-06T20:50:13.898397+00:00 app[web.1]: +--------+-------------------------------------------------+----------------+
2020-04-06T20:50:13.898397+00:00 app[web.1]: |00000000| 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0a |HTTP/1.1 200 OK.|
2020-04-06T20:50:13.898397+00:00 app[web.1]: |00000010| 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 |Content-Type: ap|
2020-04-06T20:50:13.898399+00:00 app[web.1]: |00000020| 70 6c 69 63 61 74 69 6f 6e 2f 76 6e 64 2e 63 61 |plication/vnd.ca|
2020-04-06T20:50:13.898400+00:00 app[web.1]: |00000030| 6c 63 75 6c 61 74 69 6f 6e 2b 6a 73 6f 6e 3b 76 |lculation+json;v|
2020-04-06T20:50:13.898400+00:00 app[web.1]: |00000040| 65 72 73 69 6f 6e 3d 31 2e 31 0a 43 6f 6e 74 65 |ersion=1.1.Conte|
2020-04-06T20:50:13.898400+00:00 app[web.1]: |00000050| 6e 74 2d 4c 65 6e 67 74 68 3a 20 35 33 0a 0a 5b |nt-Length: 53..[|
2020-04-06T20:50:13.898401+00:00 app[web.1]: |00000060| 0a 20 20 22 41 44 44 49 54 49 4f 4e 22 2c 0a 20 |. "ADDITION",. |
2020-04-06T20:50:13.898401+00:00 app[web.1]: |00000070| 20 22 53 55 42 54 52 41 43 54 49 4f 4e 22 2c 0a | "SUBTRACTION",.|
2020-04-06T20:50:13.898401+00:00 app[web.1]: |00000080| 20 20 22 4d 55 4c 54 49 50 4c 49 43 41 54 49 4f | "MULTIPLICATIO|
2020-04-06T20:50:13.898402+00:00 app[web.1]: |00000090| 4e 22 0a 5d |N".] |
2020-04-06T20:50:13.898402+00:00 app[web.1]: +--------+-------------------------------------------------+----------------+
2020-04-06T20:50:13.898467+00:00 app[web.1]: 20:50:13.898 [nioEventLoopGroup-3-4] DEBUG i.n.handler.logging.LoggingHandler - [id: 0x1efddaa2, L:/172.18.27.14:59829 - R:/10.11.43.12:20716] FLUSH
2020-04-06T20:50:13.898847+00:00 app[web.1]: 20:50:13.898 [nioEventLoopGroup-3-4] TRACE i.v.w.f.b.n.s.NettyInboundHandler - Reply sent
The conclusion was that perhaps we were not closing the client socket properly (even though using curl has the same problems). In any case we tried server socket eager closing to close the socket right after a response to an HTTP request. The assumption was that maybe the close would flush socket buffers (small responses). This also didn't work for us.
All of the above worked from the beginning on direct AWS use, and continues to work there.
We are currently looking into some ideas we got about timeouts and DNS configuration, but so far it's not panning out.
At this point we are stuck and don't know what to do or try next. We would sure like to support Heroku. If you have any clues to share we would appreciate it very much.
An Android app that I am writing acquires data compressed using LZString and sent out as base 64. I am using this implementation for LZString in Java along with this one in PHP. Both of these implementations are the top recomendations listed here by the author of the original JavaScript port of LZW.
I have had a really tough time understanding why the LZString data sent out by PHP throw up exceptions in Java. After much experiment and frayed nerves I have eventually worked out that the issue is down to apparent padding that is expected in Java and is missing in the data sent out from PHP. Take the following as examples
Original String being compressed
Betty bought a bit of butter but it was bitter so she bought some better butter to make the bitter butter better
a sentence I use for testing since with it multiple repetitions it is likely to compress well.
The PHP implementation of LZString spits out the following byte array
69 73 85 119 76 109 67 101 65 69 66 71 68 50 66 88 65 53 103 67 122 78 65
104 110 65 108 104 43 65 90 110 73 104 67 65 69 55 69 90 55 81 68 117 109 65
122 114 113 82 102 102 78 80 97 105 72 69 109 104 113 119 76 90 100 89 52 77
79 85 113 105 75 89 78 118 48 119 66 114 76 109 69 53 77 74 52 115 99 79 90
65
while the Java implementation generates the following byte array
69 73 85 119 76 109 67 101 65 69 66 71 68 50 66 88 65 53 103 67 122 78 65
104 110 65 108 104 43 65 90 110 73 104 67 65 69 55 69 90 55 81 68 117 109 65
122 114 113 82 102 102 78 80 97 105 72 69 109 104 113 119 76 90 100 89 52 77
79 85 113 105 75 89 78 118 48 119 66 114 76 109 69 53 77 74 52 115 99 79 90
65 **65 65 61 61**
You will note that the Java implementation tags on extra **AA==**.
I can at a pinch understand why there is an == - padding to get to the desired length multiple. However, I cannot understand why or where the AA are coming from.
I tested LZString.decompressFromBase64 in Java after tagging on an additional AA== and found that it works. On the other hand simply tagging on an == threw an exception. Further experiment revealed that tagging on ==== worked and so too did BB== indicating that these four bytes are simply used for padding and not put to any other use.
At this point I could quite simply append padding as appropriate in Java prior to doing LZString.decompressFromBase64. However, that I fear that would be a "solution" implemented without a full understanding of what is happening here. Perhaps someone here can shed some light?
I have an applet installed on a JavaCard. I want to delete this applet through over the air(OTA) message by sending APDU commands. following are the APDU command I send through card reader to delete th applet:
1) A4 04 00 00
2) ExAuth 00 02 00 01 00 404142434445464748494A4B4C4D4E4F
3) 80 E4 00 00 0D 4F 0B A0 00 00 00 00 01 02 03 03 01 02
4) 80 E4 00 00 0D 4F 0B A0 00 00 00 00 01 02 03 03 00 00
I have followed this :
https://adywicaksono.wordpress.com/2008/05/21/understanding-gsm-0348/
But I have not been able to delete the applet as there is some error everytime.
Thank You.
Under my assumption that your JavaCard is using the Global Platform framework (which almost every JavaCard does) you need to perform the following steps:
Select CardManager
Authenticate
Delete the applet
You probably succeeded the first step, although selecting the Cardmanager by its AID is the better way to go. The second step looks a bit weird to me from what you posted. The third step looks good as well.
To authenticate there are diffrent protocols, e.g. SCP01, SCP02, etc. SCP02 is the de facto standard for modern cards. Then of course you also need the right keys to authenticate, for most cards delivired there are the default keys that you already have. The exact procedure is explained in the Global Platform specification. A sample log from my tool looks like this:
=> 00 A4 04 00 08 A0 00 00 01 51 00 00 00 00 .........Q....
(9407 usec)
<= 6F 64 84 08 A0 00 00 01 51 00 00 00 A5 58 9F 65 od......Q....X.e
01 FF 9F 6E 06 47 91 23 47 41 00 73 49 06 07 2A ...n.G.#GA.sI..*
86 48 86 FC 6B 01 60 0B 06 09 2A 86 48 86 FC 6B .H..k.`...*.H..k
02 02 02 63 09 06 07 2A 86 48 86 FC 6B 03 64 0B ...c...*.H..k.d.
06 09 2A 86 48 86 FC 6B 04 02 55 65 0B 06 09 2B ..*.H..k..Ue...+
85 10 86 48 64 02 01 03 66 0C 06 0A 2B 06 01 04 ...Hd...f...+...
01 2A 02 6E 01 02 90 00 .*.n....
Status: No Error
cm> set-key 255/1/DES-ECB/404142434445464748494a4b4c4d4e4f 255/2/DES-ECB/404142434445464748494a4b4c4d4e4f 255/3/DES-ECB/404142434445464748494a4b4c4d4e4f
cm> init-update 255
=> 80 50 00 00 08 7D 62 4D F4 89 F6 07 E3 00 .P...}bM......
(55368 usec)
<= 00 00 42 87 00 17 97 93 24 74 FF 02 00 01 3C 2B ..B.....$t....<+
97 86 B8 3B 57 0A D0 9F 82 BF AD C2 90 00 ...;W.........
Status: No Error
cm> ext-auth plain
=> 84 82 00 00 10 EA 1A 9D A0 24 E6 00 9E F8 84 96 .........$......
1A 77 71 46 B4 .wqF.
(56879 usec)
<= 90 00 ..
Status: No Error
cm> delete ff4563686f4170706c6574
=> 80 E4 00 00 0D 4F 0B FF 45 63 68 6F 41 70 70 6C .....O..EchoAppl
65 74 00 et.
(956894 usec)
<= 00 90 00 ...
Status: No Error
As you don't want to perform all the cryptographic protocol by yourself there are tools out there, that do the job for you. The best freeware tool in my opinion is GlobalPlatformPro from Martin Paljek. Beware that there are plenty other tools that might be deprecated.
In order to perform remote application management on SIM you need to have OTA keys of SIM card and OTA platform to construct appropriate GSM 03.48 and 03.40 APDU commands to exchange secure data packets with SIM. SIM carries out authentication of mobile user in mobile networks and neither GSM nor OTA keys of SIM cards never shared by mobile operators to 3rd parties.
MNOs have OTA platform which maintains relational database to keep MSISDN-ICCID-OTA Keys(KiK,KiD and KiC) triplet. Apart from OTA keys, SPI, TAR and CNTR values as part of each SIM card profile is kept in OTA platform to generate GSM 03.48 packet. So to perform any applet provisioning (instal, update delete) generally secure data content must be encrypted with KiC and KiD.
I have a java card. How I can find the algorithms that the card support and use for it's cryptography? What happens when I click on the authenticate button in jcmanager (for example)? How I can authenticate with APDUs?
This is output of jcmanager when I clicked on Authenticate :
Open terminal ...
EstablishContext(): ...
Wait for card in a certain reader ...
Pick reader ...
**********************
Selecting Card Manager
***********************
-> 00 A4 04 00 08 A0 00 00 00 03 00 00 00
<- 6F 10 84 08 A0 00 00 00 03 00 00 00 A5 04 9F 65 01 FF 90 00
************
Init Update
*************
-> 80 50 00 00 08 D3 90 22 B2 C5 7C D4 DD
<- 00 00 11 60 01 00 7F 8B 0A F9 02 02 00 99 3E 01 33 1B 3F 8E 33 BA E4 AD 82 6E 3C C1 90 00
HostChallenge: D3 90 22 B2 C5 7C D4 DD
CardChallenge: 3E 01 33 1B 3F 8E
Card Calculated Card Cryptogram: 33 BA E4 AD 82 6E 3C C1
Derivation Data is 01 82 00 99 00 00 00 00 00 00 00 00 00 00 00 00
Host Cryptogram Data (to encrypt) 00 99 3E 01 33 1B 3F 8E D3 90 22 B2 C5 7C D4 DD 80 00 00 00 00 00 00 00
Card Cryptogram Data (to encrypt for verification) D3 90 22 B2 C5 7C D4 DD 00 99 3E 01 33 1B 3F 8E 80 00 00 00 00 00 00 00
S_ENC: CE 69 1B 1E C8 EC DB B0 0A 9B 18 4A 53 58 04 BB CE 69 1B 1E C8 EC DB B0
The Current session MAC key is F8 85 4D 94 19 BC 83 4C 99 BA E9 94 15 00 A6 B8
The Current session DEK key is 6D 72 48 D4 23 BF 3B 1C 7C 2F 1F BC 7C 04 E9 F6
Encrypted CardCryptoGram is 58 20 23 4E 14 8B FE AA F8 6D 14 20 3D 41 18 E4 33 BA E4 AD 82 6E 3C C1
Encrypted HostCryptoGram is 07 D0 B3 EB 0F 1B 7E 54 84 34 08 6C 5F D9 E5 55 4B 5F 0D F6 87 52 99 2E
-> 84 82 03 00 10 4B 5F 0D F6 87 52 99 2E 17 29 AA 68 12 98 CE 2D
<- 90 00
Authenticated
Is this right :
I send a random 8 byte number to the card:
-> 80 50 00 00 08 D3 90 22 B2 C5 7C D4 DD
and in the answer of my command, card give me a random numbers + the encrypted random number that I sent to the card. What happens next? my card and my reader with which algorithm encrypt and decrypt random numbers (cardchallenge and host challenge)?
you are totally mixing up things.
FIRST there is Global Platform. Global Platform specifies how to interact with the card manager/security domain: e.g. how to authenticate with the card manager, how to upload a cap file, how to install a cap file, to lock the card to unlock the card to change the keys you mentioned above etc...
SECOND there is the Java Card applet which you code in a way you want your smartcard to behave lateron.
your question is very unclear.
do you mean cryptographic algorithms regarding global platform or jor java card code?
for first identiy your card and read the corresponding Global Platform Specification, there are various authentication modes called scp01 scp02 ...
if you mean javacard: the JC Specification is not mandatory so its the manufactureres choice what crypto to implement. to find out you can either trial&error or you talk to the manufacturer
for authentication to the card manager you should always use a tool (either GPJ GPshell or JCOP tools<--last one is not freely available) generating the APDUs and crypto behind it instead of manually sending APDUs.
however, if you want to know the details read Global Platform Specification instead of asking on a forum
The algorithms supported by your particular card can be obtained via JCAlgTest project. JCAlgTest project page also provides results for 63+ cards gathered by other users. Use ATR of your card to search for similar one in JCAlgTest database. Alternatively, use ATR parsing tool and find match your card by name. The JCAlgTest project also provides performance comparison for selected cards.
I have an apache james mail server hosted on a local machine. It uses a self signed certificate which I added to the trusted list. I am trying to send and receive mails using java mail
I get this error:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
The SSL debug output however says that a trusted certificate is found. Otherwise it doesn't tell me much. I should also mention that this mail server works with openssl as well as with thunderbird.
Code for the receiving of mails:
String host = "192.168.1.21";
Boolean debug = true;
POP3Folder folder = null;
Store store = null;
try {
Properties props = new Properties();
props.put("mail.host", host);
props.put("mail.store.protocol", "pop3s");
props.put("mail.pop3s.port", "995");
Session session = Session.getInstance(props,null);
session.setDebug(debug);
store = session.getStore("pop3s");
store.connect(username, password);
The exception is thrown when I attempt to connect.
I have been banging my head against the wall for the last couple of hours/days so any help would be greatly appreciated.
EDIT:
The SSL debug output:
Info: ***
Info: Found trusted certificate:
Info: [
[
Version: V3
Subject: CN=192.168.1.21, OU=private, O=private, L=pretoria, ST=gauteng, C=za
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 22201738425808301357843951429131863923295077691776461029270738957881925042102429206972015246280434827640419315658812269457485815395646018000726167885520466978079051879949885421741485411500412697981582621030362804785391242469536810788864680524659094190388912471585546967116467038492937424356023436763640787748242238829212068970215212531761712168559272937198654805596431568611192706600640030995533703350490664304506975658770991265086884832523665903150599863152070395170101007238711948275224105410201713594276436919539183706721126654808927498591115057177598201458589477257783098334024997797269658976390073190289972335957
public exponent: 65537
Validity: [From: Thu May 01 13:28:37 CAT 2014,
To: Wed Jul 30 13:28:37 CAT 2014]
Issuer: CN=192.168.1.21, OU=private, O=private, L=pretoria, ST=gauteng, C=za
SerialNumber: [ 618a1f7d]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 90 DF D4 14 E8 B7 70 38 28 F0 7F CC 83 60 3E 98 ......p8(....`>.
0010: DC EB 0B D5 ....
]
]
]
Algorithm: [SHA256withRSA]
Signature:
0000: 13 42 F1 F0 FB C4 A4 AD 1B 93 96 CE 53 64 72 4A .B..........SdrJ
0010: D2 C5 C7 66 18 BA 07 A6 C3 C6 97 9F E4 D1 8B 6F ...f...........o
0020: B9 72 3C F6 1C 3F 98 FB 3C 6C 74 A3 20 83 99 9A .r<..?..<lt. ...
0030: 9D 91 41 32 59 71 63 4A 3B 84 2E 2D 72 9F 2D AA ..A2YqcJ;..-r.-.
0040: 83 84 56 78 19 F9 8A AF DD 11 D5 C5 21 9E 93 06 ..Vx........!...
0050: 4D 48 2D 22 12 1F DA 1F 40 6A AD 9A 9A 29 4F 52 MH-"....#j...)OR
0060: 2D EB EB A7 13 B9 27 11 35 94 02 25 4E DF E5 6C -.....'.5..%N..l
0070: 6B 12 79 DD 22 E9 BB FE 20 34 4F B4 A1 CE E2 14 k.y."... 4O.....
0080: EE A4 B4 A8 D5 2D 9F 80 82 5E 71 03 49 B3 30 3C .....-...^q.I.0<
0090: 56 06 E3 62 2E 1C 5A E4 EE 15 4A 03 77 1C 94 4C V..b..Z...J.w..L
00A0: 20 D7 47 95 62 7F 21 22 CB 64 BF A0 34 D6 D5 AD .G.b.!".d..4...
00B0: 57 C1 A3 AD 69 70 DB 32 A5 B6 38 BB 1F 00 C7 5A W...ip.2..8....Z
00C0: 3A 73 3B 8D EE 2E A8 40 9A 24 D0 58 5C D5 A4 2D :s;....#.$.X\..-
00D0: 0F 09 2E DB 84 CF 55 21 79 C8 22 B5 2D E7 91 51 ......U!y.".-..Q
00E0: 05 8A 7D 1A 19 25 CC 30 EC 9B BA 77 78 9E 2E C9 .....%.0...wx...
00F0: 6C 2D F3 47 E9 44 1E 5A 41 92 14 11 9B E4 8E 59 l-.G.D.ZA......Y
]
Info: *** ServerHelloDone
Info: *** ClientKeyExchange, RSA PreMasterSecret, TLSv1
Info: http-listener-1(2), WRITE: TLSv1 Handshake, length = 262
Info: SESSION KEYGEN:
Info: PreMaster Secret:
Info: 0000:
Info: 03
//infos continue with things in between like CONNECTION KEYGEN: etc
//many more things like this
//continued
http-listener-1(2), WRITE: TLSv1 Change Cipher Spec, length = 1
Info: *** Finished
Info: verify_data: {
Info: 121
Info: ,
Info: 89
//many more infos
Info: }
Info: ***
Info: http-listener-1(2), WRITE: TLSv1 Handshake, length = 48
Info: http-listener-1(2), READ: TLSv1 Alert, length = 2
Info: http-listener-1(2)
Info: , RECV TLSv1 ALERT:
Info: fatal,
Info: handshake_failure
Info: %% Invalidated: [Session-2, TLS_RSA_WITH_AES_128_CBC_SHA]
Info: http-listener-1(2), called closeSocket()
Info: http-listener-1(2), handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
How exactly did you add the certificate to the "trusted list"?
Have you seen this JavaMail FAQ entry?
You can also try setting the mail.pop3s.ssl.trust property to "*" or to the name of your server.
BTW, in your code, you don't need to set mail.store.protocol or mail.pop3s.port. The former is not needed because you pass the protocol name to the getStore method explicitly. The latter is not needed because it's the default for the "pop3s" protocol.
I checked with a JSK SSL expert, who had this to say:
There is so much missing from this log, it's hard to tell what's really gone on.
There seems to be a problem with the decrypt/de-pad/de-MAC operation on the server side.
They took out the most important byte (second) of the RSA Premaster Secret:
Info: PreMaster Secret:
Info: 0000:
Info: 03
If I had to guess, I would suggest trying:
java -Dcom.sun.net.ssl.rsaPreMasterSecretFix=true App
then switch to false.
Other comments:
EJP seems to think this is a rehandshake, the only hint is "Session-2". There could have been a second handshake on this connection, but those are usually only done in the case of asking for Client Authentication, but there is no CertificateRequest between the Certificate and the ServerHelloDone, so probably not that.
This could very likely be just the second separate connection made by this process.
This has nothing to do with trust, the handshake wouldn't proceed past the ServerHelloDone if that didn't succeed.
In the case of any handshake, the client sends the ChangeCipherSpec, then the next packet is a Finished packet with verify_data which is encrypted using the just negotiated keys (48 bytes = 4 Header + 12 verify_data + 20 MAC + 12 padding). If the server can't decrypt/de-pad(AES-CBC)/de-MAC properly, then it will send back a handshake_failure, which seems to be the case.
There seems to be a problem with that decrypt/de-pad/de-MAC operation. The problem could be on the server side (most likely), or perhaps they put in a replacement provider on the client side?