<div dir="ltr"><div><div><div>Hi,<br><br></div>It turns out that unintialization of record type in the while loop during building of TLS records in tls.c is wreaking havoc on ppc64. I have come up with a preliminary patch for upstream review which is although being a one liner required some extensive debugging:<br><br>diff -urNp strongswan-5.2.2/src/libtls/tls.c strongswan-5.2.2-test/src/libtls/tls.c<br>--- strongswan-5.2.2/src/libtls/tls.c 2014-05-21 08:00:31.000000000 -0400<br>+++ strongswan-5.2.2-test/src/libtls/tls.c 2015-01-08 00:27:28.524867037 -0500<br>@@ -295,6 +295,7 @@ METHOD(tls_t, build, status_t,<br> /* query upper layers for new records, as many as we can get */<br> while (TRUE)<br> {<br>+ type = 0;<br> status = this->protection->build(this->protection, &type, &data);<br> switch (status)<br> {<br><br> <br></div>Another way could be to add a new member for tls_content_type_t something like TLS_RECORD/CONTENT_TYPE_INITIALIZATION = 0. Any feedback is appreciated.<br><br></div>Thanks<br>Avesh<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 5:12 PM, Avesh Agarwal <span dir="ltr"><<a href="mailto:avesh.ncsu@gmail.com" target="_blank">avesh.ncsu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi,<br><br></div>I think that the issue is NOT 64 bit sequence number on ppc64 but the following comparison in the code:<br><br> if (*type == TLS_CHANGE_CIPHER_SPEC)<br> {<br> this->seq_out = 0;<br> return status;<br> }<br><br></div>It seems that at some point the above if clause is being true only on ppc64 even though there is no TLS_CHANGE_CIPHER_SPEC being sent. It causes the sequence number to set to 0 from 2 but at the receiver side, sequence number 2 is expected and failure occurs.<br><br></div><div><div>Thanks<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Avesh<br></div><div> <br></div></font></span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 3:35 PM, Avesh Agarwal <span dir="ltr"><<a href="mailto:avesh.ncsu@gmail.com" target="_blank">avesh.ncsu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi,<br><br></div>The issue seems to be happening on ppc64 TLS client or server due to the switch to 64 bit sequence number from 32 bit sequence in earlier releases.<br><br></div>Thanks<span><font color="#888888"><br>Avesh<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 2:51 PM, Avesh Agarwal <span dir="ltr"><<a href="mailto:avesh.ncsu@gmail.com" target="_blank">avesh.ncsu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi,<br><br></div>It seems that sequence number are not being treated correctly on ppc64. When ppc64 calculated assoc structure, it comes up with: 00 00 00 00 00 00 00 00 17 03 03 00 F5<br><br></div>Whereas x86_64 server is expecting 00 00 00 00 00 00 00 02 17 03 03 00 F5.<br><br></div>And thats why signature verification is falling, because seq number on ppc64 client calculated for type 17 is 0 whereas on x86_64 it is 2. But yet to see why this discrepancy is happening at ppc64 client only during this particular exchange.<br><br></div>Thanks <br><span><font color="#888888">Avesh<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 1:36 PM, Avesh Agarwal <span dir="ltr"><<a href="mailto:avesh.ncsu@gmail.com" target="_blank">avesh.ncsu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi,<br><br></div>I investigated this issue further, and I found that it is following during signature verification in the following code at server side in src/libtls/tls_aead_expl.c: <br><br> if (!this->signer->get_signature(this->signer, assoc, NULL) ||<br> !this->signer->verify_signature(this->signer, *data, mac))<br> {<br> return FALSE;<br> }<br><br></div>It seems that ppc64 client is sending different signature that what is expected by x86_64 server. <br><br></div>The weird part is that it happens only during following exchange, (these logs have customized debug messages inserted by me) . Any encryption/decryption/signature verification before this exchange works fine . The culprit seems the following assoc structure: 0: 00 00 00 00 00 00 00 02 17 03 03 00 F4 when sent from ppc64 client.<br><br></div>x86_64 server side logs:<br><br>Jan 7 10:30:22 10[TLS] 112: 00 00 00 00 00 00 04 00 00 00 25 16 37 2E 31 20 ..........%.7.1<br>Jan 7 10:30:22 10[TLS] 128: 42 65 74 61 20 28 4D 61 69 70 6F 29 20 70 70 63 Beta (Maipo) ppc<br>Jan 7 10:30:22 10[TLS] 144: 36 34 00 00 00 00 00 00 00 00 00 03 00 00 00 1C 64..............<br>Jan 7 10:30:22 10[TLS] 160: 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 00 ................<br>Jan 7 10:30:22 10[TLS] 176: 00 00 00 00 00 00 00 05 00 00 00 24 03 01 00 00 ...........$....<br>Jan 7 10:30:22 10[TLS] 192: 32 30 31 35 2D 30 31 2D 30 35 54 31 38 3A 33 39 2015-01-05T18:39<br>Jan 7 10:30:22 10[TLS] 208: 3A 33 35 5A 00 00 00 00 00 00 00 0B 00 00 00 10 :35Z............<br>Jan 7 10:30:22 10[TLS] 224: 00 00 00 00 00 00 00 00 00 00 00 0C 00 00 00 10 ................<br>Jan 7 10:30:22 10[TLS] 240: 00 00 00 00 ED B9 C3 BD A0 7E 68 13 BC C9 10 D5 .........~h.....<br>Jan 7 10:30:22 10[TLS] 256: 9E 6F 11 9C CE E7 3F AC 07 07 07 07 07 07 07 07 .o....?........., 272<br>Jan 7 10:30:22 10[TLS] decrypt tls_aead_expl.c, after padding: 5.5: => 264 bytes @ 0x7f138e0ec495<br>Jan 7 10:30:22 10[TLS] 0: 00 00 00 00 00 00 00 07 00 00 00 F4 00 00 00 01 ................<br>Jan 7 10:30:22 10[TLS] 16: 02 00 00 01 00 00 00 E4 00 00 00 00 00 00 00 06 ................<br>Jan 7 10:30:22 10[TLS] 32: 00 00 00 1F 41 63 63 65 70 74 2D 4C 61 6E 67 75 ....Accept-Langu<br>Jan 7 10:30:22 10[TLS] 48: 61 67 65 3A 20 65 6E 80 00 00 00 00 00 00 01 00 age: en.........<br>Jan 7 10:30:22 10[TLS] 64: 00 00 BD 00 00 00 00 00 00 00 01 00 01 FF FF 01 ................<br>Jan 7 10:30:22 10[TLS] 80: 00 00 00 B2 91 5E F6 00 00 00 00 00 00 00 02 00 .....^..........<br>Jan 7 10:30:22 10[TLS] 96: 00 00 18 00 09 08 00 00 52 65 64 20 48 61 74 00 ........Red Hat.<br>Jan 7 10:30:22 10[TLS] 112: 00 00 00 00 00 00 04 00 00 00 25 16 37 2E 31 20 ..........%.7.1<br>Jan 7 10:30:22 10[TLS] 128: 42 65 74 61 20 28 4D 61 69 70 6F 29 20 70 70 63 Beta (Maipo) ppc<br>Jan 7 10:30:22 10[TLS] 144: 36 34 00 00 00 00 00 00 00 00 00 03 00 00 00 1C 64..............<br>Jan 7 10:30:22 10[TLS] 160: 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 00 ................<br>Jan 7 10:30:22 10[TLS] 176: 00 00 00 00 00 00 00 05 00 00 00 24 03 01 00 00 ...........$....<br>Jan 7 10:30:22 10[TLS] 192: 32 30 31 35 2D 30 31 2D 30 35 54 31 38 3A 33 39 2015-01-05T18:39<br>Jan 7 10:30:22 10[TLS] 208: 3A 33 35 5A 00 00 00 00 00 00 00 0B 00 00 00 10 :35Z............<br>Jan 7 10:30:22 10[TLS] 224: 00 00 00 00 00 00 00 00 00 00 00 0C 00 00 00 10 ................<br>Jan 7 10:30:22 10[TLS] 240: 00 00 00 00 ED B9 C3 BD A0 7E 68 13 BC C9 10 D5 .........~h.....<br>Jan 7 10:30:22 10[TLS] 256: 9E 6F 11 9C CE E7 3F AC .o....?., 264<br>Jan 7 10:30:22 10[TLS] decrypt tls_aead_expl.c, mac: 6.25: => 20 bytes @ 0x7f138e0ec589<br>Jan 7 10:30:22 10[TLS] 0: ED B9 C3 BD A0 7E 68 13 BC C9 10 D5 9E 6F 11 9C .....~h......o..<br>Jan 7 10:30:22 10[TLS] 16: CE E7 3F AC<br>Jan 7 10:30:22 10[TLS] decrypt tls_aead_expl.c, after mac: 6.5: => 244 bytes @ 0x7f138e0ec495<br>Jan 7 10:30:22 10[TLS] 0: 00 00 00 00 00 00 00 07 00 00 00 F4 00 00 00 01 ................<br>Jan 7 10:30:22 10[TLS] 16: 02 00 00 01 00 00 00 E4 00 00 00 00 00 00 00 06 ................<br>Jan 7 10:30:22 10[TLS] 32: 00 00 00 1F 41 63 63 65 70 74 2D 4C 61 6E 67 75 ....Accept-Langu<br>Jan 7 10:30:22 10[TLS] 48: 61 67 65 3A 20 65 6E 80 00 00 00 00 00 00 01 00 age: en.........<br>Jan 7 10:30:22 10[TLS] 64: 00 00 BD 00 00 00 00 00 00 00 01 00 01 FF FF 01 ................<br>Jan 7 10:30:22 10[TLS] 80: 00 00 00 B2 91 5E F6 00 00 00 00 00 00 00 02 00 .....^..........<br>Jan 7 10:30:22 10[TLS] 96: 00 00 18 00 09 08 00 00 52 65 64 20 48 61 74 00 ........Red Hat.<br>Jan 7 10:30:22 10[TLS] 112: 00 00 00 00 00 00 04 00 00 00 25 16 37 2E 31 20 ..........%.7.1<br>Jan 7 10:30:22 10[TLS] 128: 42 65 74 61 20 28 4D 61 69 70 6F 29 20 70 70 63 Beta (Maipo) ppc<br>Jan 7 10:30:22 10[TLS] 144: 36 34 00 00 00 00 00 00 00 00 00 03 00 00 00 1C 64..............<br>Jan 7 10:30:22 10[TLS] 160: 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 00 ................<br>Jan 7 10:30:22 10[TLS] 176: 00 00 00 00 00 00 00 05 00 00 00 24 03 01 00 00 ...........$....<br>Jan 7 10:30:22 10[TLS] 192: 32 30 31 35 2D 30 31 2D 30 35 54 31 38 3A 33 39 2015-01-05T18:39<br>Jan 7 10:30:22 10[TLS] 208: 3A 33 35 5A 00 00 00 00 00 00 00 0B 00 00 00 10 :35Z............<br>Jan 7 10:30:22 10[TLS] 224: 00 00 00 00 00 00 00 00 00 00 00 0C 00 00 00 10 ................<br>Jan 7 10:30:22 10[TLS] 240: 00 00 00 00 ...., 244<br>Jan 7 10:30:22 10[TLS] decrypt tls_aead_expl.c, assoc: 6.75: => 13 bytes @ 0x7f138e0ec350<br>Jan 7 10:30:22 10[TLS] 0: 00 00 00 00 00 00 00 02 17 03 03 00 F4 ............., 13<br>Jan 7 10:30:22 10[TLS] decrypt tls_aead_expl.c: 7<br>Jan 7 10:30:22 10[TLS] TLS record decryption failed<br>Jan 7 10:30:22 10[TLS] sending fatal TLS alert 'bad record mac'<br><br><div><br></div><div>At ppc64 client side logs:<span><br><br>sending PB-TNC CDATA batch (228 bytes) for Connection ID 1<br></span>=> 228 bytes @ 0x1000c66d1d0<span><br> 0: 02 00 00 01 00 00 00 E4 00 00 00 00 00 00 00 06 ................<br> 16: 00 00 00 1F 41 63 63 65 70 74 2D 4C 61 6E 67 75 ....Accept-Langu<br> 32: 61 67 65 3A 20 65 6E 80 00 00 00 00 00 00 01 00 age: en.........<br> 48: 00 00 BD 00 00 00 00 00 00 00 01 00 01 FF FF 01 ................<br></span> 64: 00 00 00 B2 91 5E F6 00 00 00 00 00 00 00 02 00 .....^..........<span><br> 80: 00 00 18 00 09 08 00 00 52 65 64 20 48 61 74 00 ........Red Hat.<br> 96: 00 00 00 00 00 00 04 00 00 00 25 16 37 2E 31 20 ..........%.7.1 <br> 112: 42 65 74 61 20 28 4D 61 69 70 6F 29 20 70 70 63 Beta (Maipo) ppc<br> 128: 36 34 00 00 00 00 00 00 00 00 00 03 00 00 00 1C 64..............<br> 144: 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 00 ................<br> 160: 00 00 00 00 00 00 00 05 00 00 00 24 03 01 00 00 ...........$....<br> 176: 32 30 31 35 2D 30 31 2D 30 35 54 31 38 3A 33 39 2015-01-05T18:39<br> 192: 3A 33 35 5A 00 00 00 00 00 00 00 0B 00 00 00 10 :35Z............<br> 208: 00 00 00 00 00 00 00 00 00 00 00 0C 00 00 00 10 ................<br> 224: 00 00 00 00 ....<br>sending PT-TLS message #1 of type 'PB-TNC Batch' (244 bytes)<br></span>encrypt tls_aead_expl.c, before encryption: 1: => 272 bytes @ 0x1000c669bd0<br> 0: 00 00 00 00 00 00 00 07 00 00 00 F4 00 00 00 01 ................<br> 16: 02 00 00 01 00 00 00 E4 00 00 00 00 00 00 00 06 ................<br> 32: 00 00 00 1F 41 63 63 65 70 74 2D 4C 61 6E 67 75 ....Accept-Langu<br> 48: 61 67 65 3A 20 65 6E 80 00 00 00 00 00 00 01 00 age: en.........<br> 64: 00 00 BD 00 00 00 00 00 00 00 01 00 01 FF FF 01 ................<br> 80: 00 00 00 B2 91 5E F6 00 00 00 00 00 00 00 02 00 .....^..........<br> 96: 00 00 18 00 09 08 00 00 52 65 64 20 48 61 74 00 ........Red Hat.<br> 112: 00 00 00 00 00 00 04 00 00 00 25 16 37 2E 31 20 ..........%.7.1 <br> 128: 42 65 74 61 20 28 4D 61 69 70 6F 29 20 70 70 63 Beta (Maipo) ppc<br> 144: 36 34 00 00 00 00 00 00 00 00 00 03 00 00 00 1C 64..............<br> 160: 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 00 ................<br> 176: 00 00 00 00 00 00 00 05 00 00 00 24 03 01 00 00 ...........$....<br> 192: 32 30 31 35 2D 30 31 2D 30 35 54 31 38 3A 33 39 2015-01-05T18:39<br> 208: 3A 33 35 5A 00 00 00 00 00 00 00 0B 00 00 00 10 :35Z............<br> 224: 00 00 00 00 00 00 00 00 00 00 00 0C 00 00 00 10 ................<br> 240: 00 00 00 00 ED B9 C3 BD A0 7E 68 13 BC C9 10 D5 .........~h.....<br> 256: 9E 6F 11 9C CE E7 3F AC 07 07 07 07 07 07 07 07 .o....?........., 272<br>encrypt tls_aead_expl.c, after encryption: 2: => 272 bytes @ 0x1000c669bd0<br> 0: 12 F6 84 24 74 97 99 02 8F B1 4C 3D 97 CC 33 D7 ...$t.....L=..3.<br> 16: A9 04 27 80 28 2B 7B CE 84 97 0B F4 ED DD 23 1F ..'.(+{.......#.<br> 32: 98 5C E1 78 E6 03 5E D5 D6 2F DD F9 D5 A1 FB 4A .\.x..^../.....J<br> 48: 32 17 43 07 F5 AF 0B FF AD 6B 29 01 E4 29 9C 36 2.C......k)..).6<br> 64: AC 2F 2B 0C 97 EE 5F 06 C4 5A A4 AC 0E CF 7E 18 ./+..._..Z....~.<br> 80: 0D 86 FA 68 0B CF 67 DC EA 17 49 4E 86 97 39 D3 ...h..g...IN..9.<br> 96: 5D 24 E1 93 01 88 C1 ED 3E DA 1C 8D 17 47 2E B8 ]$......>....G..<br> 112: 17 44 7E 0F AC 90 B7 B5 84 3E 01 7A D0 4A 13 F9 .D~......>.z.J..<br> 128: F1 F8 29 C5 C4 E4 D3 A3 A2 87 43 55 A5 CF 49 5E ..).......CU..I^<br> 144: 23 53 8A FE 1D 48 CF B8 C4 D3 4F F5 BB B5 BF EB #S...H....O.....<br> 160: 02 6C E6 74 81 0F C4 69 A8 EC 17 DD 26 CF 61 AF .l.t...i....&.a.<br> 176: 75 DC 96 A1 23 A0 1C A7 5E 0E 91 43 77 F2 69 EA u...#...^..Cw.i.<br> 192: 70 C6 2A 24 9B 8B 22 7A 12 58 03 09 9D 65 A6 19 p.*$.."z.X...e..<br> 208: 14 AD 15 E7 F5 A1 4B C8 93 D8 59 41 76 45 AE 5A ......K...YAvE.Z<br> 224: 63 73 A7 A4 FA 1D 53 8E F9 32 7F 58 32 7A 1E 66 cs....S..2.X2z.f<br> 240: A5 65 25 44 93 D8 57 27 5F CA 39 01 85 79 15 C3 .e%D..W'_.9..y..<br> 256: 04 F5 4A D9 90 9E 01 C8 DC 66 64 DA E5 86 FC FB ..J......fd....., 272<br>encrypt tls_aead_expl.c, after IV: 3: => 288 bytes @ 0x1000c66f3f0<br> 0: 71 58 04 43 29 B9 1C 01 27 95 6D AA D5 C2 9F 07 qX.C)...'.m.....<br> 16: 12 F6 84 24 74 97 99 02 8F B1 4C 3D 97 CC 33 D7 ...$t.....L=..3.<br> 32: A9 04 27 80 28 2B 7B CE 84 97 0B F4 ED DD 23 1F ..'.(+{.......#.<br> 48: 98 5C E1 78 E6 03 5E D5 D6 2F DD F9 D5 A1 FB 4A .\.x..^../.....J<br> 64: 32 17 43 07 F5 AF 0B FF AD 6B 29 01 E4 29 9C 36 2.C......k)..).6<br> 80: AC 2F 2B 0C 97 EE 5F 06 C4 5A A4 AC 0E CF 7E 18 ./+..._..Z....~.<br> 96: 0D 86 FA 68 0B CF 67 DC EA 17 49 4E 86 97 39 D3 ...h..g...IN..9.<br> 112: 5D 24 E1 93 01 88 C1 ED 3E DA 1C 8D 17 47 2E B8 ]$......>....G..<br> 128: 17 44 7E 0F AC 90 B7 B5 84 3E 01 7A D0 4A 13 F9 .D~......>.z.J..<br> 144: F1 F8 29 C5 C4 E4 D3 A3 A2 87 43 55 A5 CF 49 5E ..).......CU..I^<br> 160: 23 53 8A FE 1D 48 CF B8 C4 D3 4F F5 BB B5 BF EB #S...H....O.....<br> 176: 02 6C E6 74 81 0F C4 69 A8 EC 17 DD 26 CF 61 AF .l.t...i....&.a.<br> 192: 75 DC 96 A1 23 A0 1C A7 5E 0E 91 43 77 F2 69 EA u...#...^..Cw.i.<br> 208: 70 C6 2A 24 9B 8B 22 7A 12 58 03 09 9D 65 A6 19 p.*$.."z.X...e..<br> 224: 14 AD 15 E7 F5 A1 4B C8 93 D8 59 41 76 45 AE 5A ......K...YAvE.Z<br> 240: 63 73 A7 A4 FA 1D 53 8E F9 32 7F 58 32 7A 1E 66 cs....S..2.X2z.f<br> 256: A5 65 25 44 93 D8 57 27 5F CA 39 01 85 79 15 C3 .e%D..W'_.9..y..<br> 272: 04 F5 4A D9 90 9E 01 C8 DC 66 64 DA E5 86 FC FB ..J......fd....., 288<span><br>sending TLS ApplicationData record (288 bytes)<br><br></span></div><div>Just sending some more info assuming it might be helpful in debugging.<br></div><div><div><div><div><br></div><div>Thanks and Regards<span><font color="#888888"><br>Avesh<br></font></span></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 10:51 AM, Avesh Agarwal <span dir="ltr"><<a href="mailto:avesh.ncsu@gmail.com" target="_blank">avesh.ncsu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi,<br><br></div>I came across a bug where TLS negotiation is
failing on power pc 64 architecture with the latest release 5.2.2. I
also tested 5.2.0 and the issue is present. But the issue does not show
up with earlier 5.1.1 release. Also this does not happen on x86
architecture.<br><br></div><div>This was tested with OS IMC/IMV by using pt-tls. The client logs (ppc64) are as follows:<br></div> <br>loading IMCs from '/etc/tnc_config'<br>libimcv initialized<br>IMC 1 "OS" initialized<br>processing "/etc/redhat-release" file<br>operating system name is 'Red Hat'<br>operating system version is '7.1 Beta (Maipo) ppc64'<br>IMC 1 "OS" loaded from '/usr/lib64/strongswan/imcvs/<div>imc-os.so'<br>loaded plugins: pt-tls-client curl revocation constraints pem nonce tnc-tnccs tnc-imc tnccs-20 openssl<br>unable to load 9 plugin features (9 due to unmet dependencies)<br>created thread 01 [30359]<br>entering PT-TLS setup phase<br>36 supported TLS cipher suites:<br> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA<br> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<br> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA<br> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<br> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<br> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<br> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA<br> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<br> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA<br> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<br> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br> TLS_DHE_RSA_WITH_AES_128_CBC_SHA<br> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256<br> TLS_DHE_RSA_WITH_AES_256_CBC_SHA<br> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256<br> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br> TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br> TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256<br> TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br> TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256<br> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA<br> TLS_RSA_WITH_AES_128_CBC_SHA<br> TLS_RSA_WITH_AES_128_CBC_SHA256<br> TLS_RSA_WITH_AES_256_CBC_SHA<br> TLS_RSA_WITH_AES_256_CBC_SHA256<br> TLS_RSA_WITH_AES_128_GCM_SHA256<br> TLS_RSA_WITH_AES_256_GCM_SHA384<br> TLS_RSA_WITH_CAMELLIA_128_CBC_SHA<br> TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256<br> TLS_RSA_WITH_CAMELLIA_256_CBC_SHA<br> TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256<br> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA<br> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA<br> TLS_RSA_WITH_3DES_EDE_CBC_SHA<br>entering PT-TLS negotiation phase<br>sending offer for PT-TLS version 1<br>sending PT-TLS message #0 of type 'Version Request' (20 bytes)<br>sending Server Name Indication for '<a href="http://aaa.strongswan.org" target="_blank">aaa.strongswan.org</a>'<br>sending TLS ClientHello handshake (188 bytes)<br>sending TLS Handshake record (192 bytes)<br>processing TLS Handshake record (1571 bytes)<br>received TLS ServerHello handshake (54 bytes)<br>negotiated TLS 1.2 using suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA<br>received TLS Certificate handshake (1066 bytes)<br>received TLS server certificate 'C=CH, O=Linux strongSwan, CN=<a href="http://aaa.strongswan.org" target="_blank">aaa.strongswan.org</a>'<br>received TLS ServerKeyExchange handshake (329 bytes)<br> using certificate "C=CH, O=Linux strongSwan, CN=<a href="http://aaa.strongswan.org" target="_blank">aaa.strongswan.org</a>"<br> certificate "C=CH, O=Linux strongSwan, CN=<a href="http://aaa.strongswan.org" target="_blank">aaa.strongswan.org</a>" key: 2048 bit RSA<br> using trusted ca certificate "C=CH, O=Linux strongSwan, CN=strongSwan Root CA"<br>checking certificate status of "C=CH, O=Linux strongSwan, CN=<a href="http://aaa.strongswan.org" target="_blank">aaa.strongswan.org</a>"<br>ocsp check skipped, no ocsp found<br> fetching crl from '<a href="http://crl.strongswan.org/strongswan.crl" target="_blank">http://crl.strongswan.org/strongswan.crl</a>' ...<br> sending http request to '<a href="http://crl.strongswan.org/strongswan.crl%27." target="_blank">http://crl.strongswan.org/strongswan.crl'.</a>..<br>libcurl http request failed [6]: Could not resolve host: <a href="http://crl.strongswan.org" target="_blank">crl.strongswan.org</a>; Name or service not known<br>crl fetching failed<br>certificate status is not available<br> certificate "C=CH, O=Linux strongSwan, CN=strongSwan Root CA" key: 2048 bit RSA<br> reached self-signed root ca with a path length of 0<br>verified signature with SHA256/RSA<br>received TLS CertificateRequest handshake (102 bytes)<br>received TLS cert request for 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA<br>received TLS ServerHelloDone handshake (0 bytes)<br>sending TLS peer certificate 'C=CH, O=Linux strongSwan, OU=Accounting, CN=<a href="mailto:dave@strongswan.org" target="_blank">dave@strongswan.org</a>'<br>sending TLS Certificate handshake (1068 bytes)<br>sending TLS ClientKeyExchange handshake (66 bytes)<br>created signature with SHA256/RSA<br>sending TLS CertificateVerify handshake (260 bytes)<br>sending TLS Handshake record (1406 bytes)<br>sending TLS ChangeCipherSpec record (1 bytes)<br>sending TLS Finished handshake (12 bytes)<br>sending TLS Handshake record (64 bytes)<br>processing TLS ChangeCipherSpec record (1 bytes)<br>processing TLS Handshake record (64 bytes)<br>received TLS Finished handshake (12 bytes)<br>sending TLS ApplicationData record (64 bytes)<br>processing TLS ApplicationData record (64 bytes)<br>=> 20 bytes @ 0x3fffd13fa22d<br> 0: 00 00 00 00 00 00 00 02 00 00 00 14 00 00 00 00 ................<br> 16: 00 00 00 01 ....<br>=> 4 bytes @ 0x3fffd13fa23d<br> 0: 00 00 00 01 ....<br>received PT-TLS message #0 of type 'Version Response' (20 bytes)<br>doing SASL client authentication<br>processing TLS ApplicationData record (64 bytes)<br>=> 16 bytes @ 0x3fffd13fa22d<br> 0: 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00 01 ................<br>received PT-TLS message #1 of type 'SASL Mechanisms' (16 bytes)<br>PT-TLS authentication complete<br>entering PT-TLS data transport phase<br>assigned TNCCS Connection ID 1<br>IMC 1 "OS" created a state for IF-TNCCS 2.0 Connection ID 1: +long +excl -soh<br> over IF-T for TLS 2.0 with maximum PA-TNC message size of 2097104 bytes<br>IMC 1 "OS" changed state of Connection ID 1 to 'Handshake'<br>operating system numeric version is 7.1<br>last boot: Jan 05 18:39:35 UTC 2015, 74582 s ago<br>IPv4 forwarding is disabled<br>factory default password is disabled<br>failed to open '/var/lib/dbus/machine-id'<br>no device ID available<br>creating PA-TNC message with ID 0x7cd4e2e8<br>creating PA-TNC attribute type 'IETF/Product Information' 0x000000/0x00000002<br>=> 12 bytes @ 0x1001c84f110<br> 0: 00 09 08 00 00 52 65 64 20 48 61 74 .....Red Hat<br>creating PA-TNC attribute type 'IETF/String Version' 0x000000/0x00000004<br>=> 25 bytes @ 0x1001c849830<br> 0: 16 37 2E 31 20 42 65 74 61 20 28 4D 61 69 70 6F .7.1 Beta (Maipo<br> 16: 29 20 70 70 63 36 34 00 00 ) ppc64..<br>creating PA-TNC attribute type 'IETF/Numeric Version' 0x000000/0x00000003<br>=> 16 bytes @ 0x1001c84d240<br> 0: 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 00 ................<br>creating PA-TNC attribute type 'IETF/Operational Status' 0x000000/0x00000005<br>=> 24 bytes @ 0x1001c849ba0<br> 0: 03 01 00 00 32 30 31 35 2D 30 31 2D 30 35 54 31 ....2015-01-05T1<br> 16: 38 3A 33 39 3A 33 35 5A 8:39:35Z<br>creating PA-TNC attribute type 'IETF/Forwarding Enabled' 0x000000/0x0000000b<br>=> 4 bytes @ 0x1001c849c60<br> 0: 00 00 00 00 ....<br>creating PA-TNC attribute type 'IETF/Factory Default Password Enabled' 0x000000/0x0000000c<br>=> 4 bytes @ 0x1001c84dcc0<br> 0: 00 00 00 00 ....<br>created PA-TNC message: => 165 bytes @ 0x1001c84f130<br> 0: 01 00 00 00 7C D4 E2 E8 00 00 00 00 00 00 00 02 ....|...........<br> 16: 00 00 00 18 00 09 08 00 00 52 65 64 20 48 61 74 .........Red Hat<br> 32: 00 00 00 00 00 00 00 04 00 00 00 25 16 37 2E 31 ...........%.7.1<br> 48: 20 42 65 74 61 20 28 4D 61 69 70 6F 29 20 70 70 Beta (Maipo) pp<br> 64: 63 36 34 00 00 00 00 00 00 00 00 00 03 00 00 00 c64.............<br> 80: 1C 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 ................<br> 96: 00 00 00 00 00 00 00 00 05 00 00 00 24 03 01 00 ............$...<br> 112: 00 32 30 31 35 2D 30 31 2D 30 35 54 31 38 3A 33 .2015-01-05T18:3<br> 128: 39 3A 33 35 5A 00 00 00 00 00 00 00 0B 00 00 00 9:35Z...........<br> 144: 10 00 00 00 00 00 00 00 00 00 00 00 0C 00 00 00 ................<br> 160: 10 00 00 00 00 .....<br>creating PB-PA message type 'IETF/Operating System' 0x000000/0x00000001<br>PB-TNC state transition from 'Init' to 'Server Working'<br>creating PB-TNC CDATA batch<br>adding IETF/PB-Language-Preference message<br>adding IETF/PB-PA message<br>sending PB-TNC CDATA batch (228 bytes) for Connection ID 1<br>=> 228 bytes @ 0x1001c849b00<br> 0: 02 00 00 01 00 00 00 E4 00 00 00 00 00 00 00 06 ................<br> 16: 00 00 00 1F 41 63 63 65 70 74 2D 4C 61 6E 67 75 ....Accept-Langu<br> 32: 61 67 65 3A 20 65 6E 80 00 00 00 00 00 00 01 00 age: en.........<br> 48: 00 00 BD 00 00 00 00 00 00 00 01 00 01 FF FF 01 ................<br> 64: 00 00 00 7C D4 E2 E8 00 00 00 00 00 00 00 02 00 ...|............<br> 80: 00 00 18 00 09 08 00 00 52 65 64 20 48 61 74 00 ........Red Hat.<br> 96: 00 00 00 00 00 00 04 00 00 00 25 16 37 2E 31 20 ..........%.7.1<br> 112: 42 65 74 61 20 28 4D 61 69 70 6F 29 20 70 70 63 Beta (Maipo) ppc<br> 128: 36 34 00 00 00 00 00 00 00 00 00 03 00 00 00 1C 64..............<br> 144: 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 00 ................<br> 160: 00 00 00 00 00 00 00 05 00 00 00 24 03 01 00 00 ...........$....<br> 176: 32 30 31 35 2D 30 31 2D 30 35 54 31 38 3A 33 39 2015-01-05T18:39<br> 192: 3A 33 35 5A 00 00 00 00 00 00 00 0B 00 00 00 10 :35Z............<br> 208: 00 00 00 00 00 00 00 00 00 00 00 0C 00 00 00 10 ................<br> 224: 00 00 00 00 ....<br>sending PT-TLS message #1 of type 'PB-TNC Batch' (244 bytes)<br>sending TLS ApplicationData record (288 bytes)<br>processing TLS Alert record (48 bytes)<br><b>received fatal TLS alert 'bad record mac'<br></b>sending TLS close notify<br>sending TLS Alert record (48 bytes)<br>IMC 1 "OS" deleted the state of Connection ID 1<br>removed TNCCS Connection ID 1<br>IMC 1 "OS" terminated<br>removed TCG functional component namespace<br>removed ITA-HSR functional component namespace<br>removed IETF attributes<br>removed ITA-HSR attributes<br>removed TCG attributes<br>libimcv terminated<br><br></div></div></div><div>Server (x86-64) logs have been attached them with this email.<span><br><br><div>Please let me know if any other information is required.<br><br></div>Thanks and Regards<br></span></div><span><font color="#888888"><div>Avesh<br></div></font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>