TLS Handshake fails on some api.push.apple.com ip's

App & System Services Notifications
kinshuk OP
Created Apr ’16
Replies 9
Boosts 0
Views 9.9k
Participants 8

Hi


We are using http/2 with openssl to send out notification, but we are seeing randomly that TLS handshake fails with certain servers. Here are some tls handshake sessions


$ dig +short a api.push.apple.com
api.push-apple.com.akadns.net.
17.110.227.96
17.110.227.95
17.110.227.94
17.110.227.93
17.110.227.91
17.110.227.90
17.110.227.89
17.110.227.88


And on any of these ip's tls handshake fails


/usr/local/Cellar/openssl/1.0.2f/bin/openssl s_client -connect 17.110.227.88:443 -cert fk-universal.pem -tls1_2
CONNECTED(00000003)
140735223222352:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1460404733
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---


But from another dig it returns some good ip's


$ dig +short a api.push.apple.com
api.push-apple.com.akadns.net.
17.172.234.19
17.172.234.22
17.172.234.17
17.172.233.39
17.172.234.20
17.172.234.23
17.172.234.16
17.172.234.18


The handshake completes properly


$ /usr/local/Cellar/openssl/1.0.2f/bin/openssl s_client -connect 17.172.233.39:443 -cert universal.pem -tls1_2
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 CN = Apple IST CA 2 - G1, OU = Certification Authority, O = Apple Inc., C = US
verify return:1
depth=0 CN = api.push.apple.com, OU = management:idms.group.533599, O = Apple Inc., ST = California, C = US
verify return:1
---
Certificate chain
0 s:/CN=api.push.apple.com/OU=management:idms.group.533599/O=Apple Inc./ST=California/C=US
   i:/CN=Apple IST CA 2 - G1/OU=Certification Authority/O=Apple Inc./C=US
1 s:/CN=Apple IST CA 2 - G1/OU=Certification Authority/O=Apple Inc./C=US
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF................
-----END CERTIFICATE-----
subject=/CN=api.push.apple.com/OU=management:idms.group.533599/O=Apple Inc./ST=California/C=US
issuer=/CN=Apple IST CA 2 - G1/OU=Certification Authority/O=Apple Inc./C=US
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:0xEF+0xEF:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:0xEE+0xEE:0xED+0xED:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4836 bytes and written 2343 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 208FE7FBB961A394AF0B21B52D75A7E2A3DD87BD69573BC560FB544774D2CF18
    Session-ID-ctx:
    Master-Key: 83C76DB17084CB467BC4EE0D1020EA2450F59F3EB912F084692B355697CEB73C3F120370B9BAD6115F15015D4A0CCC5C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 14400 (seconds)
    TLS session ticket:
    0000 - e0 b1 27 c1 a5 1c ba b7-b3 0a 9b 6d 6a eb 36 37   ..'........mj.67
    -V.<..%.P.t...


    Start Time: 1460404795
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---


Any help here? Why is the dns returning some ip's which are misbeaving and fails to authenticate?

Replies  9
Boosts  0
Views  9.9k
Participants  8
jwilm_onesignal OP
Apr ’16

We're encountering this same problem. api.push.apple.com resolves to servers which accept connections on port 443 (and 2197) and immediately (or nearly immediately) close them. This isn't even a TLS error as it turns out. Opening a TCP connection without sending a TLS client hello will result in the same immediate disconnect on the bad IPs. From a Protocol level, this looks like


client: SYN
apns:   SYN + ACK
client: ACK
apns:   FIN + ACK
client  FIN + ACK
apns:   ACK


See for yourself; just `telnet api.push.apple.com 443` or with one of the known bad IPs. If these are supposed to be valid APNs servers, then there is a problem with them. The other possibility I considered is other non-APNs servers have had A records added to the api.push.apple.com domain. In either case, this is firmly an Apple problem.

0
gdeglin OP
Apr ’16

This is resolved now.

0
kinshuk OP
Apr ’16

Hi


I still see the problem to exist, could you explain how it resolved for you?

0
moserine OP
Apr ’16

definitely not resolved for me. super inconvenient for us as we try to roll out push to our new customers.

0
sideshow OP
May ’16

We are also having the same problem and can confirm that it has not been resolved.


We are using the apns2 go library (https://github.com/sideshow/apns2) to connect to the gateway.

More information here https://github.com/sideshow/apns2/issues/20

0
jonchambers OP
Aug ’16

Have any of you folks filed a bug report for this issue?

0
sideshow OP
May ’17

Apple resolved this issue shortly after I posted and we have not seen this particular issue since.

0
jerryz OP
Apr ’23

sorry to resurrect this old thread but the same issue happened this afternoon at 15:50 PDT, 2023/04/13. Lasted for about 30minutes. Settles down later with occasional handshake issues.

curl https://api.push.apple.com -v

  • About to connect() to api.push.apple.com port 443 (#0)
  • Trying 17.188.183.76...
  • Connected to api.push.apple.com (17.188.183.76) port 443 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt

CApath: none

  • NSS error -12259 (SSL_ERROR_RX_MALFORMED_SERVER_HELLO)
  • SSL received a malformed Server Hello handshake message.
  • Closing connection 0

curl: (35) SSL received a malformed Server Hello handshake message.

0
AppleTruckle OP
Apr ’23

Chiming in to say we've encountered this intermittently since mid-April as well.

0
TLS Handshake fails on some api.push.apple.com ip's
First post date Last post date
 
 
Q