I'm trying to send Eddystone UID packets with my hcitool but I cannot find it via my BLE scanner(I can find another Eddystone UID beacons around with my BLE scanner and also I can find my Eddystone URLthat has been sent with my hcitool). my command: sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 15 16 aa fe 00 e7 43 f2 ac d1 4a 82 8e a1 2c 30 11 11 11 11 11 11 could you let me know if I'm wrong about it?
you forgot the final RFU bytes at the end of the UID so the command should be
sudo hcitool -i hci0 cmd 0x08 0x0008 1f 02 01 06 03 03 aa fe 17 16 aa fe 00 e7 43 f2 ac d1 4a 82 8e a1 2c 30 11 11 11 11 11 11 00 00
Related
All values are in hexadecimal number system. On Pentium in protected mode, registers have the following value: LDTR = 06000000, GDTR = 08000000, CR3 = 10000000, DS = 14, CS = 0034 CR0 = 00000001.
If the instruction (e.g. MOV AL, [2A66] accesses the logical address 2A66, what physical address does it access? At what address is the segment descriptor located? Current memory status, looking at absolute addresses is:
........
06000000 CD 20 FF 9F 00 9A EE FE 1D F0 4F 03 22 05 8A 03
06000010 22 05 17 03 22 93 0D 04 01 01 01 00 02 FF FF FF
.........
08000000 CA 20 FF 9F 00 9A E3 FE 1D F2 4F 08 23 05 8A 07
08000010 26 05 19 03 22 05 0D 04 01 02 01 00 02 FF FA FF
.........
10000020 3A 56 21 40 2A 38 42 18 2A 56 42 40 8E 48 42 18
10000030 2A 36 42 40 9A 48 42 18 7A 56 42 20 8E 48 42 18
10000040 23 60 42 40 4E A8 42 18 5A 56 42 40 8E 48 42 18
.........
40426860 C6 06 23 99 00 80 3E 1D 96 00 74 03 E9 99 00 E8
40426870 A6 01 E8 FF 03 75 19 80 3E C4 98 00 34 00 AD 0A
40426880 13 96 00 BA E9 89 75 03 E9 17 01 C6 06 1F 99 01
40426890 B8 00 6C BE 08 98 BB 21
.........
C6011D70 C6 06 23 99 00 80 3E 1D 96 00 74 03 E9 99 00 E8
C6011D80 A6 01 E8 FF 03 75 19 80 3E C4 98 00 34 00 AD 0A
C6011D90 13 96 00 BA E9 89 75 03 E9 17 01 C6 06 1F 99 01
Could you give me some guidelines what is the problem here and what I need to know to solve it? Operating systems and registry is new to me, so I don't know what I'm supposed to do here. I don't know even where should I start.
1)I am generating a Key file and a CSR with the help of openssl commands.
When displaying the CSR information with command “ openssl req -in test_csr.pem -noout –text” I get the following printings:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=GB, O=Test
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:a6:af:51:e9:23:65:50:27:14:83:f5:c8:11:10:
b1:03:0b:c7:0d:2d:ae:09:81:d9:f8:31:ad:8e:d7:
8e:65:a8:e0:d4:b4:7e:f9:3e:99:fa:b0:43:5d:e0:
41:7a:ee:9f:90:3d:05:c0:6f:80:bb:bb:9e:dd:64:
1e:15:89:0c:bc:e6:3d:76:4e:d0:ef:5c:e4:de:34:
00:d0:ac:5c:e4:f8:73:b7:22:12:81:30:28:85:cd:
5a:bb:d6:28:c3:dc:01:67:f5:56:3a:3f:01:f3:d7:
8f:d9:19:67:90:1e:23:24:b0:58:e9:80:44:c9:36:
ae:2b:c3:81:a3:ce:de:af:8b:32:33:7d:f7:81:d7:
80:b8:d2:97:ce:8b:f3:21:2b:e8:e2:96:d0:b1:3f:
cc:dc:18:18:c1:e7:99:81:2a:e9:45:20:b7:80:39:
b3:5d:b3:ab:61:6a:61:f3:e1:7c:32:b7:a8:29:1a:
b2:e1:02:81:42:1f:b4:c3:7f:bf:21:f6:2d:4f:ec:
19:d4:3a:d4:bf:90:8a:3b:f0:24:cf:83:1b:21:ab:
b2:cb:15:38:f2:ac:1d:80:ba:33:2b:c8:f4:8d:52:
90:7a:25:2b:e5:08:68:a2:f2:84:61:2f:24:48:a9:
25:97:85:28:64:52:f9:15:91:eb:36:c6:d9:98:08:
09:d3
Exponent: 65537 (0x10001)
Attributes:
a0:00
Now when I edit the key file in DER format with an Hex editor, I get the following data
30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01 00 A6 AF 51 E9 23 65 50 27 14 83 F5 C8 11 10 B1 03 0B C7 0D 2D AE 09 81 D9 F8 31 AD 8E D7 8E 65 A8 E0 D4 B4 7E F9 3E 99 FA B0 43 5D E0 41 7A EE 9F 90 3D 05 C0 6F 80 BB BB 9E DD 64 1E 15 89 0C BC E6 3D 76 4E D0 EF 5C E4 DE 34 00 D0 AC 5C E4 F8 73 B7 22 12 81 30 28 85 CD 5A BB D6 28 C3 DC 01 67 F5 56 3A 3F 01 F3 D7 8F D9 19 67 90 1E 23 24 B0 58 E9 80 44 C9 36 AE 2B C3 81 A3 CE DE AF 8B 32 33 7D F7 81 D7 80 B8 D2 97 CE 8B F3 21 2B E8 E2 96 D0 B1 3F CC DC 18 18 C1 E7 99 81 2A E9 45 20 B7 80 39 B3 5D B3 AB 61 6A 61 F3 E1 7C 32 B7 A8 29 1A B2 E1 02 81 42 1F B4 C3 7F BF 21 F6 2D 4F EC 19 D4 3A D4 BF 90 8A 3B F0 24 CF 83 1B 21 AB B2 CB 15 38 F2 AC 1D 80 BA 33 2B C8 F4 8D 52 90 7A 25 2B E5 08 68 A2 F2 84 61 2F 24 48 A9 25 97 85 28 64 52 F9 15 91 EB 36 C6 D9 98 08 09 D3 02 03 01 00 01
I observe that in addition to the Key (from byte 33) as is it displayed in the previous step, there is extra data before the key (32 first bytes) and after the key (5 last bytes).
Does somebody know where the extra information comes from and how to decrypt it?
2)I have to test a configuration where the pair of the Keys (private and public) and the hash signature are generated in a smart card with the help of vendor API’s. With a first API I get the Public Key and Length from the smart card. With a second API I a get the hash signature data and length.
I guess that the Public key can be inserted in the CSR with openssl X509_REQ_set_pubkey API (is it correct?).
The question is: Is there an existing openssl API I can use to insert the hash signature in the CSR (something like X509_REQ_sign but without hashing and signature process that has already been done by the smart card).
Thanks.
P.L.
First 256 bytes should be structure describing certificates owner (Subject, algorithm, etc).
Last 5 bytes is the RSA public exponent - 65537 in ASN.1 encoding.
To get more information use ASN.1 decoder (or openssl asn1parse command).
Unfortunately I don't know about such function on OpenSSL and don't have time to dig into their sources, but at least it is possible to form CSR ASN.1 structure manually, that's not that hard.
I have a digital signature (RSA - PKCS#1). After decrypting it with the RSA public key I get the following 128 bytes
00 01 ff ff ff .. ff 00 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 77 51 1b f4 d7 17 d7 ad 8c 2d e5 89 2a ca e0 6d a3 c0 7d 13 4d d7 b8 01 14 87 03 00 69 e4 9b b3
PKCS#1 padding removed, 51 bytes left:
30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 77 51 1b f4 d7 17 d7 ad 8c 2d e5 89 2a ca e0 6d a3 c0 7d 13 4d d7 b8 01 14 87 03 00 69 e4 9b b3
I would like two things about this:
Is it possible to determine the hash function used? Encoded algorithm ID should be prepended to the actual body of the digest, is it possible to tell what algorithm it is from the raw bytes?
Where does the actual digest start (how long the head / digest is)?
This appears to be EMSA-PKCS1-v1_5 as described in RFC 3447, which means that after removing the header and padding, you have a DER encoding of an AlgorithmIdentifier followed by the hash value itself.
From the RFC:
For the six hash functions mentioned in Appendix B.1, the DER
encoding T of the DigestInfo value is equal to the following:
[...]
SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 || H.
So in your example, the hash value is the SHA-256 hash starting 77511bf4d7....
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I've encountered a serious bug in OpenSSL 1.0.1 on Ubuntu 12.04:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665452
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666051 <- dated Oct 3 2012!
The gist of it is that I'm able to connect to some servers but not others. Connecting to google works:
openssl s_client -connect mail.google.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
...
Protocol : TLSv1.1
Cipher : ECDHE-RSA-RC4-SHA
Session-ID: 94DB1AC8531115C501434B16A5E9B735722768581778E4FEA4D9B19988551397
Session-ID-ctx:
Master-Key: 8694BF510CD7568CBAB39ECFD32D115C511529871F3030B67A4F7AEAF957D714D3E94E4CE6117F686C975EFF21FB8708
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - fb 52 d6 d3 3c a8 75 e1-1f 1d f6 23 ab ce 55 44 .R..<.u....#..UD
0010 - 27 bf ad c4 7a 0d 83 c8-48 59 48 4b 39 bb 3c c7 '...z...HYHK9.<.
0020 - 01 1e ad b3 13 de 65 d4-e8 ea e4 35 89 83 55 8e ......e....5..U.
0030 - e4 d5 9f 60 58 51 33 9b-83 34 b9 35 3d 46 cb a3 ...`XQ3..4.5=F..
0040 - 35 7b 48 5d 7b 86 5c d5-a1 14 9d 8c 3e 93 eb fb 5{H]{.\.....>...
0050 - ac 78 75 72 9b d2 bc 67-f2 fa 5b 75 80 a6 31 d8 .xur...g..[u..1.
0060 - 71 15 85 7f 55 4d dc fb-b0 b5 33 db 6d 36 8c c6 q...UM....3.m6..
0070 - e8 f9 54 7a 29 69 87 2c-dd f3 c5 cf 26 55 6f 6e ..Tz)i.,....&Uon
0080 - 45 73 7a 1d e4 b3 be b2-92 3f 0b ed c4 1c a5 24 Esz......?.....$
0090 - 3c f0 ca a5 <...
Start Time: 1354063165
Timeout : 300 (sec)
Verify return code: 0 (ok)
But connecting to facebook doesn't:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt -cipher SRP-AES-256-CBC-SHA
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0xddd2c0 [0xddd340] (64 bytes => 64 (0x40))
0000 - 16 03 01 00 3b 01 00 00-37 03 02 50 b5 5d 75 42 ....;...7..P.]uB
0010 - c2 78 55 49 b5 2e de 4f-00 a6 a8 d5 cf 10 92 44 .xUI...O.......D
0020 - 28 62 34 d6 61 5e 88 c3-68 8b 96 00 00 04 c0 20 (b4.a^..h......
0030 - 00 ff 02 01 00 00 09 00-23 00 00 00 0f 00 01 01 ........#.......
>>> TLS 1.1 [length 003b]
01 00 00 37 03 02 50 b5 5d 75 42 c2 78 55 49 b5
2e de 4f 00 a6 a8 d5 cf 10 92 44 28 62 34 d6 61
5e 88 c3 68 8b 96 00 00 04 c0 20 00 ff 02 01 00
00 09 00 23 00 00 00 0f 00 01 01
SSL_connect:unknown state
read from 0xddd2c0 [0xde28a0] (7 bytes => 7 (0x7))
0000 - 15 03 02 00 02 02 28 ......(
SSL3 alert read:fatal:handshake failure
<<< TLS 1.1 [length 0002]
02 28
SSL_connect:error in unknown state
140581179446944:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 64 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
The facebook connection either hangs after the client sends its hello buffer and never receives the server hello response, or returns with an error code if I pass in a cipher it recognizes. This happens with both -tls1 and -ssl3. I've tried every parameter to openssl I can think of.
apt-cache showpkg openssl
...
Provides:
1.0.1-4ubuntu5.5 -
1.0.1-4ubuntu5.3 -
1.0.1-4ubuntu3 -
I've also tried every parameter I can think of to curl but with no success, because it uses openssl under the hood.
I'm concerned that Ubuntu can't establish secure connections (an astounding statement, I realize). After two solid days of beating my head against this problem, I'm basically praying at this point that someone knows a workaround. I'm considering a downgrade to OpenSSL 1.0.0 or using libcurl4-dev with gnutls-dev instead. Both solutions leave a rotten taste in my mouth. Thanks in advance for any help you can provide.
P.S. all of this work is so that my server can interface with external https REST APIs. I consider this a fundamental requirement in any webserver today, no excuses.
UPDATE: Here is my output without passing a cipher. It doesn't matter if I pass -CAfile or not either:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x14ed1a0 [0x1515bf0] (226 bytes => 226 (0xE2))
0000 - 16 03 01 00 dd 01 00 00-d9 03 02 50 b6 39 78 6a ...........P.9xj
0010 - 24 95 8e dc 62 19 37 4b-ab 77 b8 66 cd 48 ba a2 $...b.7K.w.f.H..
0020 - a1 2a f8 1d f8 c9 5d fb-9d db 84 00 00 66 c0 14 .*....]......f..
0030 - c0 0a c0 22 c0 21 00 39-00 38 00 88 00 87 c0 0f ...".!.9.8......
0040 - c0 05 00 35 00 84 c0 12-c0 08 c0 1c c0 1b 00 16 ...5............
0050 - 00 13 c0 0d c0 03 00 0a-c0 13 c0 09 c0 1f c0 1e ................
0060 - 00 33 00 32 00 9a 00 99-00 45 00 44 c0 0e c0 04 .3.2.....E.D....
0070 - 00 2f 00 96 00 41 c0 11-c0 07 c0 0c c0 02 00 05 ./...A..........
0080 - 00 04 00 15 00 12 00 09-00 14 00 11 00 08 00 06 ................
0090 - 00 03 00 ff 02 01 00 00-49 00 0b 00 04 03 00 01 ........I.......
00a0 - 02 00 0a 00 34 00 32 00-0e 00 0d 00 19 00 0b 00 ....4.2.........
00b0 - 0c 00 18 00 09 00 0a 00-16 00 17 00 08 00 06 00 ................
00c0 - 07 00 14 00 15 00 04 00-05 00 12 00 13 00 01 00 ................
00d0 - 02 00 03 00 0f 00 10 00-11 00 23 00 00 00 0f 00 ..........#.....
00e0 - 01 01 ..
>>> TLS 1.1 [length 00dd]
01 00 00 d9 03 02 50 b6 39 78 6a 24 95 8e dc 62
19 37 4b ab 77 b8 66 cd 48 ba a2 a1 2a f8 1d f8
c9 5d fb 9d db 84 00 00 66 c0 14 c0 0a c0 22 c0
21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00
84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0
03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00
9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00
41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00
12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02
01 00 00 49 00 0b 00 04 03 00 01 02 00 0a 00 34
00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09
00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15
00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f
00 10 00 11 00 23 00 00 00 0f 00 01 01
SSL_connect:unknown state
Why are you passing -cipher SRP-AES-256-CBC-SHA when connecting to graph.facebook.com? Facebook certainly doesn't support SRP: http://srp.stanford.edu/.
Does it work if you don't pass that?
Also, can you give the IP address that you're getting? With 69.171.229.17, I can reproduce that exact ClientHello (modulo the nonce and with RC4-SHA are the only cipher save the SCSV) and I get a successful handshake.
Lastly, have you tried doing over an SSH tunnel to somewhere else? Sadly, when deploying TLS features in Chrome we have repeatedly found networking hardware that breaks TLS connections. (Although I can't think of a case where -ssl3 wouldn't fix it unless the hardware was actively trying to censor connections.)
Setting the MTU on my Ubuntu box from 1500 to 1496 (due to one of our firewalls being set too low) allows me to receive a response from the server without having to reboot (be sure to call ifconfig first and write down your original MTU which should be 1500):
sudo ifconfig eth0 mtu 1496
I discovered my MTU by pinging with successively larger buffers (add 28 bytes for UDP header):
Fails for 1472 + 28 = 1500:
ping -s 1472 facebook.com
PING facebook.com (66.220.158.16) 1472(1500) bytes of data.
...
Works for 1468 + 28 = 1496:
ping -s 1468 facebook.com
PING facebook.com (69.171.229.16) 1468(1496) bytes of data.
1476 bytes from www-slb-ecmp-06-prn1.facebook.com (69.171.229.16): icmp_req=1 ttl=242 time=30.0 ms
...
With 1496 I'm now able to curl to facebook.com:
curl -v https://facebook.com
* About to connect() to facebook.com port 443 (#0)
* Trying 66.220.152.16... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
* subject: C=US; ST=California; L=Palo Alto; O=Facebook, Inc.; CN=www.facebook.com
* start date: 2012-06-21 00:00:00 GMT
* expire date: 2013-12-31 23:59:59 GMT
* subjectAltName: facebook.com matched
* issuer: O=VeriSign Trust Network; OU=VeriSign, Inc.; OU=VeriSign International Server CA - Class 3; OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: facebook.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: https://www.facebook.com/
< Content-Type: text/html; charset=utf-8
< X-FB-Debug: 3vAg1O5OG9hB/EWC+gk1Kl3WLJRGmlQDaEodirWb+i0=
< Date: Wed, 28 Nov 2012 19:52:25 GMT
< Connection: keep-alive
< Content-Length: 0
<
* Connection #0 to host facebook.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
I personally think that MTU should have absolutely nothing to do with what the user sees at the stream level with TCP so I hope the OpenSSL folks fix this. I also wish that someone would invent an automagic bug submitter for bugs that are profoundly widespread and time-sucking.
Out of curiosity, how much data is actually sent when establishing a connection to a port (using Java sockets). Is it the size of a Socket object? SocketConnection object?
Your understanding of TCP network connections seems to conflate them with electrical circuits. (Understandable, given your background.)
From a physical standpoint, there's no such thing as a connection, only data packets. Through the TCP protocol, two devices agree to establish a logical (that is, software) connection. A connection is established by a client first sending data to the remote host (SYN), the server sending data back to the client (SYN-ACK), and the client sending a final acknowledgement (ACK). All of this negotation necessarily consumes bandwidth, and when you terminate a connection, you must negotiate a completely new connection to begin sending data again.
For example, I'll connect from my machine to a local web server, 192.168.1.2:80.
First, my machine sends a TCP SYN. This sends 66 bytes over the wire: (headers deliniated with |)
0000 00 24 8c a9 4c b4 00 1e 68 66 20 79 08 00|45 00 .$..L... hf y..E.
0010 00 34 53 98 40 00 80 06 00 00 c0 a8 01 0b c0 a8 .4S.#... ........
0020 01 02|36 0a 00 50 09 ef 3a a7 00 00 00 00 80 02 ..6..P.. :.......
0030 20 00 50 c8 00 00 02 04 05 b4 01 03 03 02 01 01 .P..... ........
0040 04 02 ..
The first 14 bytes are the Ethernet frame, specifying that this packet's destination MAC address. This will typically be an upstream router, but in this case, the server happens to be on the same switch, so it's the machine's MAC address, 00:24:8c:a9:4c:b4. The source (my) MAC follows, along with the payload type (IP, 0x0800). The next 20 bytes are the IPv4 headers, followed by 32 bytes of TCP headers.
The server responds with a 62-byte SYN-ACK:
0000 00 1e 68 66 20 79 00 24 8c a9 4c b4 08 00|45 00 ..hf y.$ ..L...E.
0010 00 30 69 b9 40 00 80 06 0d b1 c0 a8 01 02 c0 a8 .0i.#... ........
0020 01 0b|00 50 36 0a d3 ae 9a 73 09 ef 3a a8 70 12 ...P6... .s..:.p.
0030 20 00 f6 9d 00 00 02 04 05 b4 01 01 04 02 ....... ......
Again, 14 bytes of Ethernet headers, 20 bytes of IP headers, and 28 bytes of TCP headers. I send an ACK:
0000 00 24 8c a9 4c b4 00 1e 68 66 20 79 08 00|45 00 .$..L... hf y..E.
0010 00 28 53 9a 40 00 80 06 00 00 c0 a8 01 0b c0 a8 .(S.#... ........
0020 01 02|36 0a 00 50 09 ef 3a a8 d3 ae 9a 74 50 10 ..6..P.. :....tP.
0030 fa f0 83 78 00 00 ...x..
14 + 20 + 20 = 54 bytes over the wire (this is the smallest possible TCP packet size, by the way – the SYN and SYN-ACK packets were larger because they included options).
This adds up to 182 bytes over the wire to establish a connection; now I can begin sending actual data to the server:
0000 00 24 8c a9 4c b4 00 1e 68 66 20 79 08 00 45|00 .$..L... hf y..E.
0010 01 9d 53 9d 40 00 80 06 00 00 c0 a8 01 0b c0 a8 ..S.#... ........
0020 01 02|36 0a 00 50 09 ef 3a a8 d3 ae 9a 74 50 18 ..6..P.. :....tP.
0030 fa f0 84 ed 00 00|47 45 54 20 2f 20 48 54 54 50 ......GE T / HTTP
0040 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 66 73 0d 0a /1.1..Ho st: fs..
...
14 Ethernet + 20 IP + 20 TCP + data, in this case HTTP.
So we can see that it costs ~182 bytes to establish a TCP connection, and an additional 162-216 bytes to terminate a TCP connection (depending on whether a 4-way FIN ACK FIN ACK or more common 3-way FIN FIN-ACK ACK termination handshake is used), adding up to nearly 400 bytes to "pulse" a connection by disconnecting and reconnecting.
Compared to the 55 bytes you'd use to send one byte of data over an already established connection, this is obviously wasteful.
What you want to do is establish one connection and then send data as-needed. If you're really bandwidth constrained, you could use UDP (which requires no handshaking at all and has an overhead of only 14 Ethernet + 20 IP + 8 UDP bytes per packet), but then you face the problem of using an unreliable transport, and having to handle lost packets on your own.
The minimum size of a TCP packet is 40 bytes. It takes three exchanged packets to create a connection, two from the client and one from the server, and four more to close it, two in each direction. The last packet in a connect exchange can also contain data, as can the first in the close exchange in each direction, which can amortize it a bit, as can combining the outgoing FIN and ACK as per #josh3736's comment below.