our td-agent encounters "fail to flush the buffer" issue, the workaround is to delete buffer file(also we back up for troubleshooting).After deletion the issue was gone.
I looked into the buffer file and hoped to find which particular log caused the issue. However I found it hard to understand, and also some output is not text.
xxxxxxxxg:~/buffer# hexdump -C buffer.q5e65a46f3e10a05be5ab55e76674e195.log
00000000 93 a6 73 79 73 6c 6f 67 ce 62 fb 83 37 b3 66 6f |..syslog.b..7.fo|
00000010 6f 20 68 74 74 70 5f 6e 6f 72 6d 61 6c 69 7a 65 |o http_normalize|
00000020 64 |d|
What does the ".b..7" mean btw "syslog" and ".fo"
Could anyone help here? Many thanks!
Related
I've just deployed a CI system based on jenkins plus sonarqube. Once Jenkins Sonnarscanner starts his part of the Pipeline I can see a lot of messages such as the following:
WARN: Invalid character encountered in file /var/jenkins_home/workspace/Pipeline Test/code/..../CodigoSitioDAO.java at line 3 for encoding UTF-8. Please fix file content or configure the encoding to be used using property 'sonar.sourceEncoding'.
Well, my sonarqube calling line is:
sh "${scannerHome}/bin/sonar-scanner \
-Dsonar.sourceEnconding=UTF-8 \
-Dsonar.projectKey=My_Project\
-Dsonar.sources=. \
-Dsonar.java.binaries=. \
-Dsonar.nodejs.executable=. \
-Dsonar.login=c9bb378b2380af844c7465424933b942d10f5d18 \
-Dsonar.host.url=http://sonarqube:9000"
}
So, once I've check the mentioned file, what I can see in line 3 is something that I think does not have to do with the warning messages: import java.sql.Connection;
Having also configured -Dsonar.sourceEncoding=UTF-8, I have to say that I don't know what is happenig.
Could anyone of you help me?
It looks to me like the file is not in UTF-8. It's quite possible (especially if you used Windows editor) that the file is saved in some platform-specific encoding and its contents does not make sense for UTF-8. Consider the following:
Clase de implementación del DAO de los códigos
The same contents has been saved as ANSI and UTF-8 (explicitly selected upon save). Now if you compare byte contents, these are not the same:
$ hexdump -C test-ansi.txt
00000000 43 6c 61 73 65 20 64 65 20 69 6d 70 6c 65 6d 65 |Clase de impleme|
00000010 6e 74 61 63 69 f3 6e 20 64 65 6c 20 44 41 4f 20 |ntaci.n del DAO |
00000020 64 65 20 6c 6f 73 20 63 f3 64 69 67 6f 73 |de los c.digos|
0000002e
$ hexdump -C test-utf8.txt
00000000 43 6c 61 73 65 20 64 65 20 69 6d 70 6c 65 6d 65 |Clase de impleme|
00000010 6e 74 61 63 69 c3 b3 6e 20 64 65 6c 20 44 41 4f |ntaci..n del DAO|
00000020 20 64 65 20 6c 6f 73 20 63 c3 b3 64 69 67 6f 73 | de los c..digos|
00000030
Note that the same character ó is encoded as f3 in ANSI and as c3 b3 in UTF-8. I believe this is what your message is about: declared encoding is UTF-8 (possibly default), but the character contents f3 is invalid under this encoding. Please double check your encoding with the hex editor.
Side note: if you copied and pasted your line directly from your file, please note that Stack Overflow was not able to decode it as well, confirming it's not UTF-8-encoded.
We noticed our Jenkins build logs were being filled with 10 times more content than we expected. This greatly increases the amount of logs that slaves have to send back to the master, which in turn makes all builds take longer, which in turn makes builds fail with spurious timeouts.
On investigation, we find the lines all have a huge URL prepended.
ha:////{320 bytes of base64 junk} Log message
ha:////{320 bytes of base64 junk} [blank line]
ha:////{320 bytes of base64 junk} Next log message
I tried decoding the base64, but it doesn't produce any structure which I'm familiar with.
I didn't want to post ours because someone who knows how to decode it might find private info in there, but I tried searching for some of the content we were seeing, and noticed that someone else had posted the same sort of thing to pastebin:
https://pastebin.com/LM7mht8W
Taking one of those URLs:
ha:////4HTWhKVov8LrT80csqfIVuXrtfeJTJod3fz9PpkDu0UAAAAAzh+LCAAAAAAAAP9b85aBtbiIQSOjNKU4P0+vIKc0PTOvWK8kMze1uCQxtyC1SC8ExvbLL0llgABGJgYmLwaB3MycnMzi4My85FTXgvzkDB8G3tScxILi1BRfsEwJg4BPVmJZon5OYl66vk9+Xrp1RRGDFNSy5Py84vycVD1nCI1qPENFAZCOr07/fwfoPj6QKXogU/TApnQ/mXCmX/k+EwOjFwNrWWJOaSrQXAGEIr/S3KTUorY1U2W5pzzohprGwMDU+O4jAJgnACXyAAAA
And decoding it (including the ////):
00000000 ff ff ff e0 74 d6 84 a5 68 bf c2 eb 4f cd 1c b2 |....t...h...O...|
00000010 a7 c8 56 e5 eb b5 f7 89 4c 9a 1d dd fc fd 3e 99 |..V.....L.....>.|
00000020 03 bb 45 00 00 00 00 ce 1f 8b 08 00 00 00 00 00 |..E.............|
00000030 00 ff 5b f3 96 81 b5 b8 88 41 23 a3 34 a5 38 3f |..[......A#.4.8?|
00000040 4f af 20 a7 34 3d 33 af 58 af 24 33 37 b5 b8 24 |O. .4=3.X.$37..$|
00000050 31 b7 20 b5 48 2f 04 c6 f6 cb 2f 49 65 80 00 46 |1. .H/..../Ie..F|
00000060 26 06 26 2f 06 81 dc cc 9c 9c cc e2 e0 cc bc e4 |&.&/............|
00000070 54 d7 82 fc e4 0c 1f 06 de d4 9c c4 82 e2 d4 14 |T...............|
00000080 5f b0 4c 09 83 80 4f 56 62 59 a2 7e 4e 62 5e ba |_.L...OVbY.~Nb^.|
00000090 be 4f 7e 5e ba 75 45 11 83 14 d4 b2 e4 fc bc e2 |.O~^.uE.........|
000000a0 fc 9c 54 3d 67 08 8d 6a 3c 43 45 01 90 8e af 4e |..T=g..j<CE....N|
000000b0 ff 7f 07 e8 3e 3e 90 29 7a 20 53 f4 c0 a6 74 3f |....>>.)z S...t?|
000000c0 99 70 a6 5f f9 3e 13 03 a3 17 03 6b 59 62 4e 69 |.p._.>.....kYbNi|
000000d0 2a d0 5c 01 84 22 bf d2 dc a4 d4 a2 b6 35 53 65 |*.\..".......5Se|
000000e0 b9 a7 3c e8 86 9a c6 c0 c0 d4 f8 ee 23 00 98 27 |..<.........#..'|
000000f0 00 25 f2 00 00 00 |.%....|
000000f6
Noticing that 1f 8b 08 looked like a gzip header, I tried cutting the file at that point and decompressed it. This gave:
00000000 ac ed 00 05 73 72 00 28 68 75 64 73 6f 6e 2e 70 |....sr.(hudson.p|
00000010 6c 75 67 69 6e 73 2e 74 69 6d 65 73 74 61 6d 70 |lugins.timestamp|
00000020 65 72 2e 54 69 6d 65 73 74 61 6d 70 4e 6f 74 65 |er.TimestampNote|
00000030 00 00 00 00 00 00 00 01 02 00 02 4a 00 10 6d 69 |...........J..mi|
00000040 6c 6c 69 73 53 69 6e 63 65 45 70 6f 63 68 4c 00 |llisSinceEpochL.|
00000050 0d 65 6c 61 70 73 65 64 4d 69 6c 6c 69 73 74 00 |.elapsedMillist.|
00000060 10 4c 6a 61 76 61 2f 6c 61 6e 67 2f 4c 6f 6e 67 |.Ljava/lang/Long|
00000070 3b 78 72 00 1a 68 75 64 73 6f 6e 2e 63 6f 6e 73 |;xr..hudson.cons|
00000080 6f 6c 65 2e 43 6f 6e 73 6f 6c 65 4e 6f 74 65 00 |ole.ConsoleNote.|
00000090 00 00 00 00 00 00 01 02 00 00 78 70 00 00 01 5f |..........xp..._|
000000a0 7b 67 ff dc 73 72 00 0e 6a 61 76 61 2e 6c 61 6e |{g..sr..java.lan|
000000b0 67 2e 4c 6f 6e 67 3b 8b e4 90 cc 8f 23 df 02 00 |g.Long;.....#...|
000000c0 01 4a 00 05 76 61 6c 75 65 78 72 00 10 6a 61 76 |.J..valuexr..jav|
000000d0 61 2e 6c 61 6e 67 2e 4e 75 6d 62 65 72 86 ac 95 |a.lang.Number...|
000000e0 1d 0b 94 e0 8b 02 00 00 78 70 00 00 00 00 02 81 |........xp......|
000000f0 ee f1 |..|
000000f2
So it kind of seems like the timestamper plugin is somehow implicated in this nonsense, but when I go and read their code, I don't see anything about this stuff.
Which bit of Jenkins is actually doing this, and is there a way to avoid it?
Good detective work, #Trejkaz. Disabling the timestamper plugin did NOT fix things for me (I left the plugin installed; perhaps I should have removed it altogether or restarted Jenkins one more time to be sure).
My best answer (the one I'm using in practice) gets rid of all the escape sequences in the console AND in the context of this question, removes all of the 'ha:////' URLs as well so I get pretty close to unadorned, complete ASCII text in my processed console log. It's worth mentioning that our site's automation culture is to allow Jenkins builds to expire except those marked for keeping, so my workflow is to produce a postprocessed console log artifact to "keep" and not to archive the original log. It's not to create a smaller log in the first place, which I saw as more time- and resource-consuming for no discernible benefit.
Presuming the raw Jenkins console log lives in console-log.txt, it's:
ansi2txt < console-log.txt | col -b | sed 's;ha:////[[:print:]]*AAAA[=]*;;g'
This eliminates escape sequences meant to provide terminal display sugar without requiring build and installation of tool packages not found in any repo (in Ubuntu ansi2txt comes from colorized-logs and col comes from bsdmainutils), removes the mysterious 'ha:////' URLs regardless of their source, and turns a raw console log that looks like:
Started by user ESC[8mha:////4AqgegZw7qQ8DI1+KvWPDM7IJMwAv+ifWfXHqdHJJeCwAAAAlx+
LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihh
k0NSjKDWzXb3RdlLBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUN
odHsLgAzWEgZu/dLi1CL9xJTczDwAj6GcLcAAAAA=ESC[0mAdmin
Checking out git ssh://git#github.com/SlipChip/PHX-Inst-App-SW.git into /var/tmp
/meta-talis/workspace/Firmware-Inst-App-SW#script to read Jenkinsfile
...
Commit message: "Add Jenkins console log as artifact console-log.txt."
> git rev-list --no-walk b70ac257fc5c87aa4a1fe55661b3523842f43412 # timeout=10
Running in Durability level: MAX_SURVIVABILITY
ESC[8mha:////4Ke8FKbo31T+wvpwDtO0m31cw6Dr9enqafGE6M9os2Y7AAAAoh+LCAAAAAAAAP9tjTEOwjAQBM8BClpKHuFItIiK1krDC0x8GCfWnbEdkooX8TX+gCESFVvtrLSa5wtWKcKBo5UdUu8otU4GP9jS5Mixv3geZcdn2TIl9igbHBs2eJyx4YwwR1SwULBGaj0nRzbDRnX6rmuvydanHMu2V1A5c4MHCFXMWcf8hSnC9jqYxPTz/BXAFEIGsfuclm8zQVqFvQAAAA==ESC[0m[Pipeline] Start of Pipeline
ESC[8mha:////4IgCbJC4forU2exyZEKrDUTKRV7HgFuwndWEBhDMO34wAAAApR+LCAAAAAAAAP9tjTEOwjAUQ3+KOrAycohUghExsUZZOEFIQkgb/d8mKe3EibgadyBQiQlLlmxL1nu+oE4RjhQdby12HpP2vA+jK4lPFLtroIm3dOGaMFGwXNpJkrGnpUrKFhaxClYC1hZ1oOTRZdiIVt1VExS65pxj2Q4CKm8GeAAThZxVzN8yR9jeRpMIf5y/AJj7DGxXvP/86jduZBmjwAAAAA==ESC[0m[Pipeline] node
...
into the considerably more palatable:
Started by user Admin
Checking out git ssh://git#github.com/SlipChip/PHX-Inst-App-SW.git into /var/tmp/meta-talis/workspace/Firmware-Inst-App-SW#script to read Jenkinsfile
...
Commit message: "Add Jenkins console log as artifact console-log.txt."
> git rev-list --no-walk b70ac257fc5c87aa4a1fe55661b3523842f43412 # timeout=10
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
which is the same as what I see in the Jenkins web interface when browsing the console log.
I hope this answer helps you in a practical sense (i.e. rather than making an O(n) walkthrough of all of your plugins searching for the 'ha:////' culprit).
I have loaded about 20000 odd nodes from the consumer complaints csv file available in the neo4j load csv example. I am using Neo4j bolt driver in my java class to query .
Driver driver = GraphDatabase.driver( "bolt://localhost/trialschema", AuthTokens.basic( "neo4j", "neo" ) );
Session session = driver.session();
StatementResult result = session.run( "MATCH(n)-[r]-(m) return n,type(r),m limit 10" );
Map<String,Object> resultOfQuery = processResult(result);
session.close();
driver.close();
return returnMap ;
But when I am trying to loop through this StatementResult, inside processResult Method, I get the below exception
There was an unexpected error (type=Internal Server Error,
status=500).
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is
org.neo4j.driver.v1.exceptions.ClientException: Trying to read message
complete ending '00 00' while there are more data left in the message
content unread: buffer [41 49 4e 53 54 b3 4e c9 77 af 91 89 43 6f 6d
70 6c 61 69 6e 74 a1 82 69 64 ca 00 1d 13 40 00 00 00 46 b1 71 93 b3
4e 07 91 87 43 6f 6d 70 61 6e 79 a1 84 6e 61 6d 65 8f 42 41 4e 4b 20
4f 46 20 41 4d 45 52 49 43 41 87 41 47 41 49 4e 53 54 b3 4e c9 77 9c
91 89 43 6f 6d 70 6c 61 69 6e 74 a1 82 69 64 ca 00 1b d4 06 00 00 00
46 b1 71 93 b3 4e 07 91 87 43 6f 6d 70 61 6e 79 a1 84 6e 61 6d 65 8f
42 41 4e 4b 20 4f 46 20 41 4d 45 52 49 43 41 87 41 47 41 49 4e 53 54
b3 4e c9 77 a4 91 89 43 6f 6d 70 6c 61 69 6e 74 a1 82 69 64 ca 00 1d
3c 54 00 00 00 46 b1 71 93 b3 4e 07 91 87 43 6f 6d 70 61 6e 79 a1 84
6e 61 6d 65 8f 42 41 4e 4b 20 4f 46 20 41 4d 45 52 49 43 41 87 41 47
41 49 4e 53 54 b3 4e c9 77 95 91 89 43 6f 6d 70 6c 61 69 6e 74 a1 82
69 64 ca 00 0b 56 ca 00 00 00 46 b1 71 93 b3 4e 07 91 87 43 6f 6d 70
61 6e 79 a1 84 6e 61 6d 65 8f 42 41 4e 4b 20 4f 46 20 41 4d 45 52 49
43 41 --------------unread chunk size 11075
I don't get this issue if I am trying to fetch only a small result by limiting the result to 50 or 100 . Can someone help ?
This may be a stupid question, but I want a simpler way to replicate this technique used by Jon Erikson in the art of exploitation. In it he fills a .bin file using a bunch of complicated stuff grepping for source code and so forth.
$ for i in $(head exploit_notesearch.c | grep "^\"" | cut -d\" -f2)
do
echo -en $i
done > shellcode.bin
This generates a file like so:
hexdump -C shellcode.bin
00000000 48 31 f6 48 31 d2 48 bb 2f 62 69 6e 2f 73 68 11 |H1.H1.H./bin/sh.|
00000010 48 c1 e3 08 48 c1 eb 08 53 48 c7 c0 3b 11 11 11 |H...H...SH..;...|
00000020 48 89 e7 48 c1 e0 38 48 c1 e8 38 0f 05 |H..H..8H..8..|
0000002d
cat shellcode.bin
H1�H1�H�/bin/shH�H�SH��;H��H��8H��8
I don't know how to replicate this witchcraft, how can I make an exact replica using different commands? I tried
cat > new.bin
x48x31xf6x48x31xd2x48xbbx2fx62x69x6ex2fx73x68x11x48xc1xe3x08x48xc1xe3x08x53x48xc7xc0x3bx11x11x11x48x89xe7x48xc1xe0x38x48xc1xe8x38x0fx05
cat new.bin
x48x31xf6x48x31xd2x48xbbx2fx62x69x6ex2fx73x68x11x48xc1xe3x08x48xc1xe3x08x53x48xc7xc0x3bx11x11x11x48x89xe7x48xc1xe0x38x48xc1xe8x38x0fx05
hexdump -C new.bin
00000000 78 34 38 78 33 31 78 66 36 78 34 38 78 33 31 78 |x48x31xf6x48x31x|
00000010 64 32 78 34 38 78 62 62 78 32 66 78 36 32 78 36 |d2x48xbbx2fx62x6|
00000020 39 78 36 65 78 32 66 78 37 33 78 36 38 78 31 31 |9x6ex2fx73x68x11|
00000030 78 34 38 78 63 31 78 65 33 78 30 38 78 34 38 78 |x48xc1xe3x08x48x|
00000040 63 31 78 65 33 78 30 38 78 35 33 78 34 38 78 63 |c1xe3x08x53x48xc|
00000050 37 78 63 30 78 33 62 78 31 31 78 31 31 78 31 31 |7xc0x3bx11x11x11|
00000060 78 34 38 78 38 39 78 65 37 78 34 38 78 63 31 78 |x48x89xe7x48xc1x|
00000070 65 30 78 33 38 78 34 38 78 63 31 78 65 38 78 33 |e0x38x48xc1xe8x3|
00000080 38 78 30 66 78 30 35 0a |8x0fx05.|
00000088
I hardly knew how to ask this question and am not aware of anywhere else to look. I am grateful for any help. Thanks.
The tool you are looking for is xxd, which is normally used to get a hex dump of a binary file, but can also be used to perform a reverse hex dump, which is what you are trying to do.
Put your ascii hex into a file called Input.txt, without any of the x's.
4831f64831d248bb2f62696e2f73681148c1e30848c1e3085348c7c03b1111114889e748c1e03848c1e8380f05
Next, run xxd with the flag -p for plain, and -r for reverse.
xxd -r -p Input.txt Output.bin
Now, the desired output should be in Output.bin.
hexdump -C Output.bin
00000000 48 31 f6 48 31 d2 48 bb 2f 62 69 6e 2f 73 68 11 |H1.H1.H./bin/sh.|
00000010 48 c1 e3 08 48 c1 e3 08 53 48 c7 c0 3b 11 11 11 |H...H...SH..;...|
00000020 48 89 e7 48 c1 e0 38 48 c1 e8 38 0f 05 |H..H..8H..8..|
0000002d
I want to show the client that my client/server app is using a secure connection with mutual authentication.
My server app is implemented using C#, and the client is using C with OpenSSL. They can talk to each other and work fine. I'm trying do this demonstration with the two solutions below, but I'm not satisfied with the results.
Monitoring the connection using SSLDump:
The output is listed below, seems to be nothing wrong with it, but not sure about that. Please help me with this.
Monitoring the connection using Wireshark, and Unsniff,
A network analysis tool, that can give me some kind of high level analysis result, could be very helpful with my demonstration. But when I watch the connection with these two tools, they all show me that the protocol is TCP, and I want they show me that protocol of the connection is SSL/TLS.
Any ideas?
Output from SSLDump:
fan#ubuntu:~/Desktop$ sudo ssldump -i eth0 port 9527 and host fan
New TCP connection #1: 192.168.181.144(60992) <-> fan.local(9527)
1 1 0.0044 (0.0044) C>S Handshake
ClientHello
Version 3.1
cipher suites
Unknown value 0xc014
Unknown value 0xc00a
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Unknown value 0x88
Unknown value 0x87
Unknown value 0xc00f
Unknown value 0xc005
TLS_RSA_WITH_AES_256_CBC_SHA
Unknown value 0x84
Unknown value 0xc012
Unknown value 0xc008
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Unknown value 0xc00d
Unknown value 0xc003
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Unknown value 0xc013
Unknown value 0xc009
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
Unknown value 0x9a
Unknown value 0x99
Unknown value 0x45
Unknown value 0x44
Unknown value 0xc00e
Unknown value 0xc004
TLS_RSA_WITH_AES_128_CBC_SHA
Unknown value 0x96
Unknown value 0x41
Unknown value 0xc011
Unknown value 0xc007
Unknown value 0xc00c
Unknown value 0xc002
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_RC4_40_MD5
Unknown value 0xff
compression methods
unknown value
NULL
1 2 0.2572 (0.2528) S>C Handshake
ServerHello
Version 3.1
session_id[32]=
5e 08 00 00 82 35 0d a1 2a 91 c2 ac cb 62 1e f5
d0 88 3a d3 1a 64 58 a3 11 be 56 ef c4 fe 73 b7
cipherSuite TLS_RSA_WITH_RC4_128_MD5
compressionMethod NULL
Certificate
CertificateRequest
certificate_types rsa_sign
certificate_types dss_sign
certificate_authority
30 4f 31 15 30 13 06 0a 09 92 26 89 93 f2 2c 64
01 19 16 05 6c 6f 63 61 6c 31 19 30 17 06 0a 09
92 26 89 93 f2 2c 64 01 19 16 09 4f 62 6a 65 63
74 69 76 61 31 1b 30 19 06 03 55 04 03 13 12 4f
62 6a 65 63 74 69 76 61 2d 42 4a 50 44 43 2d 43
41
certificate_authority
30 6f 31 0b 30 09 06 03 55 04 06 13 02 53 45 31
14 30 12 06 03 55 04 0a 13 0b 41 64 64 54 72 75
73 74 20 41 42 31 26 30 24 06 03 55 04 0b 13 1d
41 64 64 54 72 75 73 74 20 45 78 74 65 72 6e 61
6c 20 54 54 50 20 4e 65 74 77 6f 72 6b 31 22 30
20 06 03 55 04 03 13 19 41 64 64 54 72 75 73 74
20 45 78 74 65 72 6e 61 6c 20 43 41 20 52 6f 6f
74
certificate_authority
30 81 c1 31 0b 30 09 06 03 55 04 06 13 02 55 53
31 17 30 15 06 03 55 04 0a 13 0e 56 65 72 69 53
69 67 6e 2c 20 49 6e 63 2e 31 3c 30 3a 06 03 55
04 0b 13 33 43 6c 61 73 73 20 31 20 50 75 62 6c
69 63 20 50 72 69 6d 61 72 79 20 43 65 72 74 69
66 69 63 61 74 69 6f 6e 20 41 75 74 68 6f 72 69
74 79 20 2d 20 47 32 31 3a 30 38 06 03 55 04 0b
13 31 28 63 29 20 31 39 39 38 20 56 65 72 69 53
69 67 6e 2c 20 49 6e 63 2e 20 2d 20 46 6f 72 20
61 75 74 68 6f 72 69 7a 65 64 20 75 73 65 20 6f
6e 6c 79 31 1f 30 1d 06 03 55 04 0b 13 16 56 65
72 69 53 69 67 6e 20 54 72 75 73 74 20 4e 65 74
77 6f 72 6b
certificate_authority
...
certificate_authority
30 52 31 0b 30 09 06 03 55 04 06 13 02 55 53 31
0b 30 09 06 03 55 04 08 13 02 43 41 31 12 30 10
06 03 55 04 07 13 09 50 61 6c 6f 20 41 6c 74 6f
31 10 30 0e 06 03 55 04 0a 13 07 42 6f 78 2e 6e
65 74 31 10 30 0e 06 03 55 04 03 13 07 62 6f 78
2e 6e 65 74
certificate_authority
30 16 31 14 30 12 06 03 55 04 03 13 0b 58 59 5a
20 43 6f 6d 70 61 6e 79
ServerHelloDone
1 3 0.3889 (0.1316) C>S Handshake
Certificate
1 4 0.3889 (0.0000) C>S Handshake
ClientKeyExchange
1 5 0.3889 (0.0000) C>S Handshake
CertificateVerify
Signature[256]=
02 fb a2 32 cd 1f 43 6e e7 1c b6 d8 8e a0 cc 49
6e 04 17 fa 8d 86 b0 a5 98 23 b0 19 ec f2 a5 8d
65 2d 31 81 73 96 43 89 19 81 ea 60 c8 12 4a 86
99 a5 b1 7b b5 29 ee 57 46 39 32 b4 f4 df 49 e0
97 35 c8 a2 e1 12 98 21 fa 75 87 9a 84 17 82 ba
72 a1 60 0a 44 3b 72 97 88 0c 44 0b 7c 14 f5 01
1b 47 90 fb c0 0e dc ae 91 c3 a4 38 c9 b7 c5 37
52 d6 4e a1 fb d5 87 35 df a3 cb 28 ab 73 f6 c3
b5 11 48 fc db 9b 84 a2 35 b7 c8 42 df b0 7a 20
b3 20 52 f0 6c 29 ae 96 4c 32 2e ba af ea 2e ad
2d ee 2e ed da 49 f7 55 38 29 7e 90 62 a7 03 4f
cd 76 14 36 b2 e0 a6 73 f2 7c c3 04 7f c1 a7 ca
db 5b 97 84 a7 df c3 e6 a5 15 0b f1 d6 bf e0 8b
7c 62 55 c9 2b 24 2d ac 8c 7b c8 72 70 9c ef 77
c4 5b d5 32 a8 30 6f e7 43 46 f9 47 05 c6 b9 4a
9d 98 6b f4 b6 bd 82 14 ec 65 99 42 f0 a0 9b 18
1 6 0.3889 (0.0000) C>S ChangeCipherSpec
1 7 0.3889 (0.0000) C>S Handshake
1 8 0.5480 (0.1591) S>C ChangeCipherSpec
1 9 0.5480 (0.0000) S>C Handshake
1 10 0.5502 (0.0022) C>S application_data
1 11 0.5513 (0.0011) C>S application_data
1 12 0.5517 (0.0004) C>S application_data
1 13 0.5521 (0.0004) C>S application_data
1 14 0.6444 (0.0923) S>C application_data
1 15 9.8598 (9.2153) C>S application_data
1 16 10.2293 (0.3694) C>S application_data
1 12.3329 (2.1035) C>S TCP FIN
1 12.3401 (0.0072) S>C TCP FIN
This looks like a normal SSL/TLS negotiation with a Client and Server certificate exchange. However at least the client and maybe the server look like they are running TLS 1.0. The use of TLS 1.2 and a more secure block cipher could be good depending on your security requirements.