ssl socket write gives connection reset exception - sockets

I am trying to send ios push notification using javapns library . the code is working fine on java 6 but not working on java 7 . I am trying to write on a ssl socket by java code
this.socket.getOutputStream().write(bytes);
but getting following exception : -
2015-09-24 02:01:17,330 [JavaPNS grouped notification thread in LIST
mode] ERROR javapns.notification.PushNotificationManager
(PushNotificationManager.java:496) - Delivery error
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196) ~[?:1.7.0_79]
at java.net.SocketInputStream.read(SocketInputStream.java:122) ~[?:1.7.0_79]
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442) ~[?:1.7.0_79]
at sun.security.ssl.InputRecord.read(InputRecord.java:480) ~[?:1.7.0_79]
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
~[?:1.7.0_79]
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
~[?:1.7.0_79]
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:709)
~[?:1.7.0_79]
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
~[?:1.7.0_79]
at java.io.OutputStream.write(OutputStream.java:75) ~[?:1.7.0_79]
at javapns.notification.PushNotificationManager.sendNotification(PushNotificationManager.java:464)
[utils-1.0.jar:?]
at javapns.notification.PushNotificationManager.sendNotification(PushNotificationManager.java:409)
[utils-1.0.jar:?]
at javapns.notification.transmission.NotificationThread.runList(NotificationThread.java:283)
[utils-1.0.jar:?]
at javapns.notification.transmission.NotificationThread.run(NotificationThread.java:254)
[utils-1.0.jar:?]
at java.lang.Thread.run(Thread.java:745) [?:1.7.0_79]
Following are my ssl debug log : -
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: ........
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 22222491044564264786925450301128660800404037455402211937155693765439451266775814064935111308236503917661658380453607223444671197507922227372310694498331784203397249559620562506847738658137494429967865235154139927237328515659798669693649542833648664525838898423359833650942229563615420055801398510282090750116916759108752545159033267269553610447830532132801594757535863574777003658295660123855620269370519852284530709335738820289388013418673721050782042119531816409879900413319632795054390149130447840278225455201462347192736907867086706041266601675705875530393925455170420669674672723643704537136254104782678046353641
public exponent: 65537
Validity: [From: Thu Jul 16 12:10:32 IST 2015,
To: Fri Jul 15 12:10:32 IST 2016]
Issuer: CN=Apple Worldwide Developer Relations Certification Authority, OU=Apple Worldwide Developer Relations, O=Apple Inc., C=US
SerialNumber: [ 25dea3f4 f4f072b3]
Certificate Extensions: 8
[1]: ObjectId: 1.2.840.113635.100.6.1.2 Criticality=true
Extension unknown: DER encoded OCTET string =
0000: 04 02 05 00 ....
[2]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
[
accessMethod: ocsp
accessLocation: URIName: http://ocsp.apple.com/ocsp03-wwdr01
]
]
[3]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 88 27 17 09 A9 B6 18 60 8B EC EB BA F6 47 59 C5 .'.....`.....GY.
0010: 52 54 A3 B7 RT..
]
]
[4]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]
[5]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [1.2.840.113635.100.5.1]
[PolicyQualifierInfo: [
qualifierID: 1.3.6.1.5.5.7.2.2
qualifier: 0000: 30 81 B6 0C 81 B3 52 65 6C 69 61 6E 63 65 20 6F 0.....Reliance o
0010: 6E 20 74 68 69 73 20 63 65 72 74 69 66 69 63 61 n this certifica
0020: 74 65 20 62 79 20 61 6E 79 20 70 61 72 74 79 20 te by any party
0030: 61 73 73 75 6D 65 73 20 61 63 63 65 70 74 61 6E assumes acceptan
0040: 63 65 20 6F 66 20 74 68 65 20 74 68 65 6E 20 61 ce of the then a
0050: 70 70 6C 69 63 61 62 6C 65 20 73 74 61 6E 64 61 pplicable standa
0060: 72 64 20 74 65 72 6D 73 20 61 6E 64 20 63 6F 6E rd terms and con
0070: 64 69 74 69 6F 6E 73 20 6F 66 20 75 73 65 2C 20 ditions of use,
0080: 63 65 72 74 69 66 69 63 61 74 65 20 70 6F 6C 69 certificate poli
0090: 63 79 20 61 6E 64 20 63 65 72 74 69 66 69 63 61 cy and certifica
00A0: 74 69 6F 6E 20 70 72 61 63 74 69 63 65 20 73 74 tion practice st
00B0: 61 74 65 6D 65 6E 74 73 2E atements.
], PolicyQualifierInfo: [
qualifierID: 1.3.6.1.5.5.7.2.1
qualifier: 0000: 16 2A 68 74 74 70 3A 2F 2F 77 77 77 2E 61 70 70 .*http://www.app
0010: 6C 65 2E 63 6F 6D 2F 63 65 72 74 69 66 69 63 61 le.com/certifica
0020: 74 65 61 75 74 68 6F 72 69 74 79 2F teauthority/
]] ]
]
[6]: ObjectId: 2.5.29.37 Criticality=true
ExtendedKeyUsages [
codeSigning
]
[7]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
]
[8]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 6F FB BD 5A 59 70 1C 2E 77 32 9A 97 69 C3 23 0E o..ZYp..w2..i.#.
0010: EF D8 E9 D0 ....
]
]
]
Algorithm: [SHA256withRSA]
Signature:
0000: 90 BE B9 5B E7 66 C1 B4 C1 C8 60 90 69 5F 01 04 ...[.f....`.i_..
0010: 2B C4 E6 9E 8D 13 8C A7 3F 81 55 6C CD D1 47 48 +.......?.Ul..GH
0020: 3C D7 D8 3E F5 C2 69 A7 A2 21 CE 15 08 F7 D9 8C <..>..i..!......
0030: 2D FE 37 29 AD DC E3 CA 27 27 83 2C 15 95 4D 40 -.7)....''.,..M#
0040: EA 2C AD EF 99 7C 9B 84 59 3F 6C E6 BA 07 F4 EC .,......Y?l.....
0050: 05 36 E4 58 EA B0 DF 00 AB 54 F2 FF 6B AE C2 C1 .6.X.....T..k...
0060: E4 3C D3 23 79 61 D1 67 DD 0C 0D 2B 77 E0 8E 6F .<.#ya.g...+w..o
0070: A2 7B 21 13 D2 4F D7 8B 98 A7 E0 22 E9 95 D7 1A ..!..O....."....
0080: C5 71 0A 15 35 77 38 37 EC F9 CC 60 79 2D A5 E0 .q..5w87...`y-..
0090: DA C2 78 AD 59 88 7B 92 93 66 9A 44 F7 58 8C 0D ..x.Y....f.D.X..
00A0: 28 E3 42 D0 79 DC F5 23 C7 36 D0 61 0A 34 61 F3 (.B.y..#.6.a.4a.
00B0: 16 AE 7B D8 8B BC B8 6B D6 05 C4 E4 EF B0 BF 4B .......k.......K
00C0: 66 E1 6F 59 EC 67 F6 A3 C0 49 7A 83 8A 7B FC 7B f.oY.g...Iz.....
00D0: 26 3C 42 16 F7 DE DB 74 4D 1A A5 7F AE C2 36 C4 &<B....tM.....6.
00E0: 8E 5A F9 75 05 3A A5 13 70 0C 69 96 00 CB FD 77 .Z.u.:..p.i....w
00F0: 4A 9E C8 E4 AA 39 75 7D 6D C9 79 04 BC DF 59 EF J....9u.m.y...Y.
]
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
JavaPNS grouped notification thread in LIST mode, WRITE: TLSv1 Handshake, length = 1729
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 00 2E C1 C7 9F 24 B2 E9 02 59 7B D2 8A A7 .......$...Y....
0010: 22 D3 72 B2 16 55 5F 5C E1 30 7D 4A 56 F1 3C 32 ".r..U_\.0.JV.<2
0020: 5D 77 8F 13 BD B0 E9 6A 84 9E 81 0D 0B 38 D5 0E ]w.....j.....8..
CONNECTION KEYGEN:
Client Nonce:
0000: 56 03 10 94 63 A2 8C A1 6D 75 2F F0 38 EC CD 4F V...c...mu/.8..O
0010: 3A D6 46 C7 C4 2D 5F 76 4B 38 3F FC 28 59 6B 04 :.F..-_vK8?.(Yk.
Server Nonce:
0000: B2 1F 50 60 42 F5 94 7A 5B 7C FE 50 60 3E 84 BC ..P`B..z[..P`>..
0010: CB 18 B7 B1 E8 50 56 6E F9 DD 6E E2 B9 34 25 01 .....PVn..n..4%.
Master Secret:
0000: 03 87 6A 7D 0E 69 76 FA 5F 2E 48 BB B7 77 79 0F ..j..iv._.H..wy.
0010: 5E 59 CF 32 BA B5 D7 2E 0F 9D 43 F2 4F F1 CD 52 ^Y.2......C.O..R
0020: DF A7 05 EB 47 BF FD 18 48 F0 DD F1 78 10 47 FF ....G...H...x.G.
Client MAC write Secret:
0000: ED B5 4A 85 1D CC 96 D2 D0 94 29 40 AE 8F C3 10 ..J.......)#....
0010: 74 52 24 8D tR$.
Server MAC write Secret:
0000: B9 ED CD B7 30 52 1F 74 9E 47 71 41 2A 1B 90 C7 ....0R.t.GqA*...
0010: AF 2F 93 4E ./.N
Client write key:
0000: A0 B0 7C 23 2F C7 A3 5D 24 03 B4 1F F9 2B B2 97 ...#/..]$....+..
Server write key:
0000: 29 4C 64 FB 39 02 96 43 7A 5B F5 1D D4 2A 51 B7 )Ld.9..Cz[...*Q.
Client write IV:
0000: 85 3C C4 38 B4 9F 41 92 B6 88 7A 47 F6 B9 82 C1 .<.8..A...zG....
Server write IV:
0000: FA 04 7C A8 D7 29 A3 0D 5F 20 BF 3C 4C C8 52 9A .....).._ .<L.R.
*** CertificateVerify
JavaPNS grouped notification thread in LIST mode, WRITE: TLSv1 Handshake, length = 262
JavaPNS grouped notification thread in LIST mode, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data: { 221, 26, 21, 239, 125, 223, 149, 73, 149, 170, 46, 218 }
***
JavaPNS grouped notification thread in LIST mode, WRITE: TLSv1 Handshake, length = 48
JavaPNS grouped notification thread in LIST mode, handling exception: java.net.SocketException: Connection reset
%% Invalidated: [Session-2, TLS_RSA_WITH_AES_128_CBC_SHA]
JavaPNS grouped notification thread in LIST mode, SEND TLSv1 ALERT: fatal, description = unexpected_message
JavaPNS grouped notification thread in LIST mode, WRITE: TLSv1 Alert, length = 32
JavaPNS grouped notification thread in LIST mode, Exception sending alert: java.net.SocketException: Broken pipe
JavaPNS grouped notification thread in LIST mode, called closeSocket()
JavaPNS grouped notification thread in LIST mode, called close()
JavaPNS grouped notification thread in LIST mode, called closeInternal(true)
abhishek$ which openssl
/usr/bin/openssl
abhishek$ openssl version
OpenSSL 1.0.2d 9 Jul 2015
abhishek$ java -version
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
Edit : When I printed this SSLSession
SSLSession session = socket.getSession();
//I got [Session-1, SSL_NULL_WITH_NULL_NULL]
// Returns the SSL Session in use by this connection. These can be long lived, and frequently correspond to an entire login session for some user. The session specifies a particular cipher suite which is being actively used by all connections in that session, as well as the identities of the session's client and server.
This method will initiate the initial handshake if necessary and then block until the handshake has been established.
If an error occurs during the initial handshake, this method returns an invalid session object which reports an invalid cipher suite of "SSL_NULL_WITH_NULL_NULL".
System.out.println(session.getLocalCertificates());
// I got null
While Using same certificates in java 6 I did not get null .


The peer has closed the connection. You would have to look at its logs to see why. Possibly it asked you for a certificate and you didn't provide one.

Related

Unknown data between h264 NAL units in an AVC file

I want to understand a weird observation I had while working with h264 encoded AVC files. In such files, each NAL unit is preceded by 1/2/4 bytes that encode the size of the NAL unit (without the size header). However, there has been some cases where the end of one NAL unit doesn't take to another NAL unit, instead it takes to a sequence of some data till it eventually reaches another NAL unit
For example, starting at 01ADF399, we have:
*00 00 35 99 41* 9A 12 25 83 A5 F0 7A 08 41 0C 1E 02 50 20 03 80 A4 12 30 B6 44 90
0C E1 CD A2 68 9F 9F 2E C0 2E 1C 18 A2 28 8A 85 65 AC 0B 7D F1 DD 0F ...
Which ends at 01AE2936 as:
21 1A 54 6D FC 34 3B 32 FA AA D6 71 8A BC 92 F9 95 79 75 8A E6 B5 A9 77 24 4A AC
1C E3 EF A2 9D 97 30 51 D1 7B EB 75 FD B2 8D 8A A7 B9 47 8A C6 59 1A 32 FB 9E 77
03 8E CA 67 23 B7 52 EE 2E A4 BA 43 CE F9 CD 46 48 C5 C4 41 35 32 F3 D6 5B CD BE
DA B8 B3 3E 1B 33 87 AE 65 A0 45 74 DF EB 37 96 2F DA 9C ...
Clearly not the start of an NAL unit (since FC doesn't have forbidden zero bit)
However, at 01AE7535, we have the following:
00 00 27 EA 41 9A 14 29 81 29 7C 80 41 04 18 98 44 64 01 C6 54 00 0D 9F 34 58 71
E5 0A A6 CD B0 4B 38 60 7F E6 1F C8 00 24 7A 06 E5 9B 21 99 F0 51 24 9B ...
Which is the start of an NAL unit. I verified that those two NAL units are consecutive since filtering the file to the annex B h264 format removes the unknown data in between and places those two exact NAL units right next to each other.
I tried looking at ISO 14496 part 15 but it doesn't mention anything about this.

Swift/URLSession returns a different public key than OpenSSL

I have this code (can be run in a playground):
import UIKit
import CryptoKit
let url: URL = URL(string: "https://apple.com")!
final class SSLExtractor: NSObject, URLSessionDelegate {
private var session: URLSession!
init(url: URL) {
super.init()
let session = URLSession.init(configuration: .default, delegate: self, delegateQueue: nil)
session.dataTask(with: url).resume()
}
func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: #escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust,
let serverTrust = challenge.protectionSpace.serverTrust,
let publicKey = SecTrustCopyKey(serverTrust),
let publicKeyData = SecKeyCopyExternalRepresentation(publicKey, nil)
else { return }
let publicKeyHash = SHA256.hash(data: publicKeyData as Data)
print("publicKey: \(publicKey)")
print("publicKey: \(publicKeyData)")
print("publicKey: \((publicKeyData as Data).base64EncodedString() )")
print(publicKeyHash)
}
}
let extractor = SSLExtractor(url: url)
Supposedly the last print should give me the server's public key:
SHA256 digest: b0faa00170de7c1ac7994644efadb59f149656546394bd22c95527e78f1984b6
However, when I use OpenSSL:
$ openssl s_client -connect apple.com:443 | openssl x509 -pubkey -noout | openssl rsa -pubin -outform der| openssl dgst -sha256
I get a different hash:
1786e93d8e16512ea34ea1475e39597e77d7e39239ba1a97dcd71f97e64d6619
How to get the correct hash ?
Edit: Also tried
let certificate = SecTrustGetCertificateAtIndex(serverTrust, 0),
let certifKey = SecCertificateCopyKey(certificate),
let certifPubKey = SecKeyCopyPublicKey(certifKey),
let certifPubKeyData = SecKeyCopyExternalRepresentation(certifPubKey, nil)
But I got the same result

Only sort of an answer but too much for comments. You found that the 'external' publickey provided (and hashed) by Swift is a suffix of that used by OpenSSL.
OpenSSL uses, as I referenced, the 'SPKI' (SubjectPublicKeyInfo) structure defined by X.509/PKIX=RFC5280 section 4 which is a DER-encoded ASN.1 SEQUENCE containing an AlgorithmIdentifier and a BIT STRING cotaining embedded algorithm-specific data. RFC 7468 section 13 (which partly officializes OpenSSL, although it doesn't say so) confirms this is the content of a 'standard' public key representation, and RFC 3279 section 2.3.1 defines that for RSA (which the Apple cert's key is) the content of the BIT STRING part is the ASN.1 structure RSAPublicKey which actually was defined (though 3279 doesn't say so for the key, while it does for the signature in 2.2.1) in PKCS1 currently RFC8017 section A.1.1 (but unchanged from earlier versions).
Because of the way DER encoding works, the content of the BIT STRING -- in this case the ASN.1 structure RSAPublicKey -- is exactly a suffix of the encoding of the whole SPKI.
If we look at, and parse, the SPKI OpenSSL gets from the cert (with x509 -pubkey)
$ openssl rsa -pubin -in applespki -outform der |od -Ax -tx1
writing RSA key
000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01
000010 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01
000020 00 e0 e5 ca aa 34 ea 32 d1 f5 e3 56 e5 05 e8 07
000030 c3 d3 3b 86 93 60 94 37 20 9f 8d d0 17 8f ba da
000040 16 f1 b2 6a bc 41 7a 6f dc 22 87 4b 05 e8 57 48
000050 56 3c da a2 02 e5 57 73 94 95 18 dd 7c c9 b0 68
000060 fe 17 2c 8b 6f fa 42 a9 b1 a8 77 88 22 d4 41 08
000070 08 d9 80 59 92 bc e9 3a 0a 17 e0 2b 13 fe bf ec
000080 69 7d 61 15 14 21 71 73 a0 70 fd 6d a0 0f 46 13
000090 60 8d c1 bd 8c 66 60 04 05 e0 44 f0 a1 53 b7 00
0000a0 7f a3 f3 55 da d2 6c c6 dd 7f 83 79 1f 6e cb 1d
0000b0 78 3e d9 9f fa 58 34 38 41 c5 70 c1 c7 dd ea b0
0000c0 81 c0 d4 a3 18 a4 da 02 15 b8 cb 48 10 fa 42 86
0000d0 75 1c 55 51 6b 48 6e 37 43 98 09 af 4f 52 c0 c8
0000e0 75 40 a5 e7 65 ba 62 2a be 6c 2a 6d 72 5b 82 21
0000f0 d1 75 97 ea 7e 21 a1 04 f4 76 7c 85 db 50 c7 9f
000100 b5 d8 f7 80 15 ba a5 83 9e 2c da f0 73 c6 14 9a
000110 fd 35 07 41 4b 53 21 8d 0d 01 f1 05 b3 04 05 83
000120 cb 02 03 01 00 01
000126
$ openssl asn1parse -i -dump -in applespki1
0:d=0 hl=4 l= 290 cons: SEQUENCE
4:d=1 hl=2 l= 13 cons: SEQUENCE
6:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption
17:d=2 hl=2 l= 0 prim: NULL
19:d=1 hl=4 l= 271 prim: BIT STRING
0000 - 00 30 82 01 0a 02 82 01-01 00 e0 e5 ca aa 34 ea .0............4.
0010 - 32 d1 f5 e3 56 e5 05 e8-07 c3 d3 3b 86 93 60 94 2...V......;..`.
0020 - 37 20 9f 8d d0 17 8f ba-da 16 f1 b2 6a bc 41 7a 7 ..........j.Az
0030 - 6f dc 22 87 4b 05 e8 57-48 56 3c da a2 02 e5 57 o.".K..WHV<....W
0040 - 73 94 95 18 dd 7c c9 b0-68 fe 17 2c 8b 6f fa 42 s....|..h..,.o.B
0050 - a9 b1 a8 77 88 22 d4 41-08 08 d9 80 59 92 bc e9 ...w.".A....Y...
0060 - 3a 0a 17 e0 2b 13 fe bf-ec 69 7d 61 15 14 21 71 :...+....i}a..!q
0070 - 73 a0 70 fd 6d a0 0f 46-13 60 8d c1 bd 8c 66 60 s.p.m..F.`....f`
0080 - 04 05 e0 44 f0 a1 53 b7-00 7f a3 f3 55 da d2 6c ...D..S.....U..l
0090 - c6 dd 7f 83 79 1f 6e cb-1d 78 3e d9 9f fa 58 34 ....y.n..x>...X4
00a0 - 38 41 c5 70 c1 c7 dd ea-b0 81 c0 d4 a3 18 a4 da 8A.p............
00b0 - 02 15 b8 cb 48 10 fa 42-86 75 1c 55 51 6b 48 6e ....H..B.u.UQkHn
00c0 - 37 43 98 09 af 4f 52 c0-c8 75 40 a5 e7 65 ba 62 7C...OR..u#..e.b
00d0 - 2a be 6c 2a 6d 72 5b 82-21 d1 75 97 ea 7e 21 a1 *.l*mr[.!.u..~!.
00e0 - 04 f4 76 7c 85 db 50 c7-9f b5 d8 f7 80 15 ba a5 ..v|..P.........
00f0 - 83 9e 2c da f0 73 c6 14-9a fd 35 07 41 4b 53 21 ..,..s....5.AKS!
0100 - 8d 0d 01 f1 05 b3 04 05-83 cb 02 03 01 00 01 ...............
we can see the content of the BIT STRING, skipping the first byte 00 because of the way DER works for BIT STRING, and thus starting at offset 24=0x18 and continuing to the end, is itself a DER encoding of RSAPublicKey (30 82 01 0a is the SEQUENCE, 02 82 01 01 ... is the INTEGER (signed) modulus, 02 03 01 00 01 is the INTEGER (signed) publicExponent). OpenSSL 1.0.0 up (which is now ubiquitous, though I remember when it wasn't) can extract this, and get your expected hash:
$ openssl rsa -pubin -in applespki -RSAPublicKey_out -outform der |od -Ax -tx1
writing RSA key
000000 30 82 01 0a 02 82 01 01 00 e0 e5 ca aa 34 ea 32
000010 d1 f5 e3 56 e5 05 e8 07 c3 d3 3b 86 93 60 94 37
000020 20 9f 8d d0 17 8f ba da 16 f1 b2 6a bc 41 7a 6f
000030 dc 22 87 4b 05 e8 57 48 56 3c da a2 02 e5 57 73
000040 94 95 18 dd 7c c9 b0 68 fe 17 2c 8b 6f fa 42 a9
000050 b1 a8 77 88 22 d4 41 08 08 d9 80 59 92 bc e9 3a
000060 0a 17 e0 2b 13 fe bf ec 69 7d 61 15 14 21 71 73
000070 a0 70 fd 6d a0 0f 46 13 60 8d c1 bd 8c 66 60 04
000080 05 e0 44 f0 a1 53 b7 00 7f a3 f3 55 da d2 6c c6
000090 dd 7f 83 79 1f 6e cb 1d 78 3e d9 9f fa 58 34 38
0000a0 41 c5 70 c1 c7 dd ea b0 81 c0 d4 a3 18 a4 da 02
0000b0 15 b8 cb 48 10 fa 42 86 75 1c 55 51 6b 48 6e 37
0000c0 43 98 09 af 4f 52 c0 c8 75 40 a5 e7 65 ba 62 2a
0000d0 be 6c 2a 6d 72 5b 82 21 d1 75 97 ea 7e 21 a1 04
0000e0 f4 76 7c 85 db 50 c7 9f b5 d8 f7 80 15 ba a5 83
0000f0 9e 2c da f0 73 c6 14 9a fd 35 07 41 4b 53 21 8d
000100 0d 01 f1 05 b3 04 05 83 cb 02 03 01 00 01
00010e
$ openssl rsa -pubin -in applespki -RSAPublicKey_out -outform der |openssl sha256
writing RSA key
(stdin)= b0faa00170de7c1ac7994644efadb59f149656546394bd22c95527e78f1984b6
This only works for RSA. It might be interesting to see how your Swift code handles a certificated non-RSA key, although at present those are hard to find on the public web; the only stable ones I currently know of are at 'badssl' like https://ecc256.badssl.com .

How is this data encoded?

I've found several website exchange data with the browser through a seemingly similar encoding consisting of [A-z0-9/+] such as
11UmFuZG9tSVYkc2RlIyh9YWJdm48m5cJDWuLLIYaigN6cCfiKOtB/Xb00yCTJRLU1iZilyDQAF8okuqrX2gHm2pVsKeYHWxDNNLB9teqqv2msRNJADEmHqHJWhIpgq6kB4LRtzrU7x1ms9VfChurilER4JfNiBiNqsetbxxPaDn3+SZFhbqDh1V6ufUeNbri49YKKra3WOe4=
or
11UmFuZG9tSVYkc2RlIyh9YWJdm48m5cJDWuLLIYaigN6cCfiKOtB/Xb00yCTJRLU1iZilyDQAF8okuqrX2gHm2pVsKeYHWxDN9IdK3oj1qFvfsjLKRaHSu60i6RSRagBfu5CtrYWAiHIZXA5wKwOGZwh5lUwHApYhPZzbdpfT6ubbVr5WFlrO5VHDBw9bFi1hduxQaia2i8k=
or
11UmFuZG9tSVYkc2RlIyh9YUbM7JQKVn66Jan93YWDhnDQ1nd8g669ScUfvmjw724qB521xitv+brNAzNRj46wgJBqF3rIKqgVRRsk8d9ccybqIhLm0E76CUjS/XnuWXzxZM+wTAx8lSbkiqHWg7hcwb7Fr8bMqW0d+1gZqUJto3zdImOPwDTNRFmEmRhWnOEAV86C5yFfCyw=
It appears to be more than a simple ID - rather encoded data of some sort.
I've tried Base 64 - the second half (following the /) appears to be a valid base64 encoding of non Text data.
The hex values of the example strings (base64 decoded after the /) are:
5d bd 34 c8 24 c9 44 b5 35 89 98 a5 c8 34 00 17 ca 24 ba aa d7 da 01 e6 da 95 6c 29 e6 07 5b 10 cd 34 b0 7d b5 ea aa bf 69 ac 44 d2 40 0c 49 87 a8 72 56 84 8a 60 ab a9 01 e0 b4 6d ce b5 3b c7 59 ac f5 57 c2 86 ea e2 94 44 78 25 f3 62 06 23 6a b1 eb 5b c7 13 da 0e 7d fe 49 91 61 6e a0 e1 d5 5e ae 7d 47 8d 6e b8 b8 f5 82 8a ad ad d6 39 ee
5d bd 34 c8 24 c9 44 b5 35 89 98 a5 c8 34 00 17 ca 24 ba aa d7 da 01 e6 da 95 6c 29 e6 07 5b 10 cd f4 87 4a de 88 f5 a8 5b df b2 32 ca 45 a1 d2 bb ad 22 e9 14 91 6a 00 5f bb 90 ad ad 85 80 88 72 19 5c 0e 70 2b 03 86 67 08 79 95 4c 07 02 96 21 3d 9c db 76 97 d3 ea e6 db 56 be 56 16 5a ce e5 51 c3 07 0f 5b 16 2d 61 76 ec 50 6a 26 b6 8b c9
5e 7b 96 5f 3c 59 33 ec 13 03 1f 25 49 b9 22 a8 75 a0 ee 17 30 6f b1 6b f1 b3 2a 5b 47 7e d6 06 6a 50 9b 68 df 37 48 98 e3 f0 0d 33 51 16 61 26 46 15 a7 38 40 15 f3 a0 b9 c8 57 c2 cb

Verifying if the delegated kerberos credential is proper

I am currently trying to enable a spnego based SSO Application.
As part of this I seek to get the delegated credentials.
How to verify that the credential I get after
GSSContext.acceptSecContext(gss, 0, gss.length); is a delegated credential or not.
GSSContext.getCredDelegState() is true.
My primary doubt is whether the server principal in the ticket should be
krbtgt/ABC.XYZ.COM#ABC.XYZ.COM or should be the service (HTTP/host.ABC.XYZ.com) for which the ticket was delegated?``
Delegated Credential is.....[GSSCredential:
client#ABC.XYZ.COM 1.2.840.113554.1.2.2 Initiate [Ticket (hex) =
0000: 61 81 F3 30 81 F0 A0 03 02 01 05 A1 0F 1B 0D 55 a..0...........A
0010: 53 2E 4F 52 41 43 4C 45 2E 43 4F 4D A2 22 30 20 BC.XYZ.COM."0
0020: A0 03 02 01 00 A1 19 30 17 1B 06 6B 72 62 74 67 .......0...krbtg
0030: 74 1B 0D 55 53 2E 4F 52 41 43 4C 45 2E 43 4F 4D t..ABC.XYZ.COM
0040: A3 81 B3 30 81 B0 A0 03 02 01 01 A1 03 02 01 01 ...0............
0050: A2 81 A3 04 81 A0 35 DF 47 76 64 F4 79 80 7C 2B ......5.Gvd.y..+
0060: 33 92 54 3B EA C8 F4 DE 62 19 37 AE BF 27 7C 9E 3.T;....b.7..'..
0070: BA 1D E6 BA B0 90 3D 2E 41 7E 41 0D 07 2A 2D AB ......=.A.A..*-.
0080: 33 88 11 40 69 CE 07 6E CE 84 C3 B1 95 22 CE 8B 3..#i..n....."..
0090: 76 98 01 61 C3 FA B7 CB 9F 95 C8 1F C7 AF F4 48 v..a...........H
00A0: 87 35 5D 83 CB D2 DA 86 56 2B 80 BC 33 CD A8 B8 .5].....V+..3...
00B0: 7B 8B 5E A2 D5 6C 27 F3 D6 ED 4E 77 17 68 7E C6 ..^..l'...Nw.h..
00C0: 85 00 9D B5 43 87 44 BC EA F5 67 12 12 96 B4 AE ....C.D...g.....
00D0: C6 B0 49 5C 08 9E 6F BB 7E E4 91 32 D0 0A 68 FA ..I\..o....2..h.
00E0: 9E 9C 6A 16 96 45 B6 87 58 86 ED 3B 12 EA 98 B8 ..j..E..X..;....
00F0: 6E A9 F9 3E D4 D1 n..>..
Client Principal = client#ABC.XYZ.COM
Server Principal = krbtgt/ABC.XYZ.COM#ABC.XYZ.COM
Session Key = EncryptionKey: keyType=1 keyBytes (hex dump)=
0000: 8F B5 AB AE B9 89 F1 5D
Forwardable Ticket true
Forwarded Ticket true
Proxiable Ticket false
Proxy Ticket false
Postdated Ticket false
Renewable Ticket false
Initial Ticket false
Auth Time = Mon Jun 17 03:53:45 PDT 2013
Start Time = Mon Jun 17 06:49:34 PDT 2013
End Time = Tue Jun 18 03:53:45 PDT 2013
Renew Till = null
Client Addresses Null ]]
I am using a linux based KDC and linux hosts for this.
Is there any reference to what the delegated ticket should be like?

The delegated ticket has been created for the UPN of your machine, if you use MIT/Heimdal KDC (no experience with) it's probably host/fqdn#REALM. In Windows (AD KDC) it is hostname$#REALM. Only that machine is able to extract the delegated credential.
The whole point of delegated credential is that there should be no difference between a delegated and a initial credential for an end service.

S-Box used in AES 128 bit CFB mode of encryption

Can anybody give me the S-Box used for 128 bit AES CFB mode of encryption.
Will this S-Box be same for every 128 -bit AES CFB Implementation.
Thanks

Here it is:
| 0 1 2 3 4 5 6 7 8 9 a b c d e f
---|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
00 |63 7c 77 7b f2 6b 6f c5 30 01 67 2b fe d7 ab 76
10 |ca 82 c9 7d fa 59 47 f0 ad d4 a2 af 9c a4 72 c0
20 |b7 fd 93 26 36 3f f7 cc 34 a5 e5 f1 71 d8 31 15
30 |04 c7 23 c3 18 96 05 9a 07 12 80 e2 eb 27 b2 75
40 |09 83 2c 1a 1b 6e 5a a0 52 3b d6 b3 29 e3 2f 84
50 |53 d1 00 ed 20 fc b1 5b 6a cb be 39 4a 4c 58 cf
60 |d0 ef aa fb 43 4d 33 85 45 f9 02 7f 50 3c 9f a8
70 |51 a3 40 8f 92 9d 38 f5 bc b6 da 21 10 ff f3 d2
80 |cd 0c 13 ec 5f 97 44 17 c4 a7 7e 3d 64 5d 19 73
90 |60 81 4f dc 22 2a 90 88 46 ee b8 14 de 5e 0b db
a0 |e0 32 3a 0a 49 06 24 5c c2 d3 ac 62 91 95 e4 79
b0 |e7 c8 37 6d 8d d5 4e a9 6c 56 f4 ea 65 7a ae 08
c0 |ba 78 25 2e 1c a6 b4 c6 e8 dd 74 1f 4b bd 8b 8a
d0 |70 3e b5 66 48 03 f6 0e 61 35 57 b9 86 c1 1d 9e
e0 |e1 f8 98 11 69 d9 8e 94 9b 1e 87 e9 ce 55 28 df
f0 |8c a1 89 0d bf e6 42 68 41 99 2d 0f b0 54 bb 16
It can also be found in FIPS Pub 197, the official standard.
And yes, it is exactly the same for every implementation of AES. Otherwise you wouldn't be able to encrypt something others could decrypt or vice-versa.