I captured and decrypted an HTTPS request using fiddler. It looks about like this:
CONNECT qwer1234.com:443 HTTP/1.0
User-Agent: Blabla Example/1.0
Host: qwer1234.com:443
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
Random: 13 35 55 0B F2 3C 9D A3 A2 C2 E4 3E 66 FA D3 DD E5 15 27 33 F1 E6 CD A5 E0 C4 10 4E 41 67 32 8E
SessionID: empty
Extensions:
renegotiation_info 00
server_name qwer1234.com
status_request 01 00 00 00 00
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
signature_algorithms 00 01 06 07 05 08 03 09 04 03 06 04 04 07 01 09
SessionTicket empty
Ciphers:
[003C] TLS_RSA_WITH_AES_128_CBC_SHA256
[002F] TLS_RSA_AES_128_SHA
[003D] TLS_RSA_WITH_AES_256_CBC_SHA256
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0040] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[006A] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
Compression:
[00] NO_COMPRESSION
Is this a special kind of HTTPS request? Why is only half of the request excrypted? What do the random generated numbers mean / what are they for? How would I send this request using a WinHttpRequest? How does it differ from other HTTPS requests?
I'm kind of bad in finding the right places to ask questions like this. Tell me if you think that I should have asked this on a different page and if so, where.
This isn't a HTTPS request at all, it is a CONNECT tunnel through which HTTPS traffic subsequently flows. Client applications first send a CONNECT request to the proxy (like Fiddler) to tell them where to establish a TCP/IP connection to, then after the connection establishes, a HTTPS handshake is performed and the requests are sent.
When showing you the CONNECT tunnel, Fiddler analyzes the parameters and displays them for you to read. The actual HTTPS requests will appear after this tunnel in the Web Sessions list, if and only if you have enabled HTTPS decryption in the Tools > Fiddler Options > HTTPS screen.
Related
I have setup advertising in bluez using hcitool The device sow up as expected.
The setup is done as follow:
#advertising
sudo hcitool -i hci0 cmd 0x08 0x0008 18 02 01 06 02 0a 00 11 07 9e ca dc 24 0e e5 a9 e0 93 f3 a3 b5 01 00 40 6e 00 00 00 00 00 00 00
#scan response
sudo hcitool -i hci0 cmd 0x08 0x0009 0d 0c 09 6f 6f
#setup advertising interval
sudo hcitool -i hci0 cmd 0x08 0x0006 80 02 c0 03 00 00 00 00 00 00 00 00 00 07 00
#turn advertising on
sudo hcitool -i hci0 cmd 0x08 0x000a 01
After a devie connect the advertising is gone. How kan I keep continuing advertising?
I did a workaround calling sudo hcitool -i hci0 cmd 0x08 0x000a 01 repeatedly.
Another question is how setup the advertising above using the d-bus interface.
ps.
Many info have been found in Bluetooth specification 5.0 (Core_v5.0.pdf), 7.8.5 LE Set Advertising Parameters command p.1321
Most stacks/implementations (including BlueZ) will automatically switch off adverts when a device's state switches from advertising to accepting an incoming connection. The reason for this is that according to the stack Link Layer states (Please see picture below which is available Bluetooth specification v5.1, Vol 6, Part B, Section 1.1: Link Layer States), the state of the device should change from Advertising to Connected as the device cannot be in two different states at the same time.
However, once you are in a connection you can restart your adverts as you have done manually. Please have a look at the answer below for more information:-
Link Layer state for more than one simultaneous connection
I hope this helps.
For testing HTTP protocols, I would like to use curl to make a POST (or other) request to an http server, but either have it write the request to a local file instead of the server socket, or better, simultaneously write the request to the server socket AND to a local file.
That is byte for byte what it writes to the server.
Yes, it's possible on the command line at least with --trace* options
curl --trace-time --trace-ascii - -d "some=val&other=123" http://localhost:8000
Output:
20:11:26.176533 == Info: Rebuilt URL to: http://localhost:8000/
20:11:26.180738 == Info: Trying 127.0.0.1...
20:11:26.180775 == Info: TCP_NODELAY set
20:11:26.180903 == Info: Connected to localhost (127.0.0.1) port 8000 (#0)
20:11:26.180969 => Send header, 148 bytes (0x94)
0000: POST / HTTP/1.1
0011: Host: localhost:8000
0027: User-Agent: curl/7.60.0
0040: Accept: */*
004d: Content-Length: 18
0061: Content-Type: application/x-www-form-urlencoded
0092:
20:11:26.181019 => Send data, 18 bytes (0x12)
0000: some=val&other=123
20:11:26.181029 == Info: upload completely sent off: 18 out of 18 bytes
20:11:26.181069 <= Recv header, 22 bytes (0x16)
0000: HTTP/1.1 201 CREATED
20:11:26.181091 <= Recv header, 19 bytes (0x13)
0000: Connection: Close
20:11:26.181099 <= Recv header, 2 bytes (0x2)
0000:
20:11:26.181104 <= Recv data, 12 bytes (0xc)
0000: .2019-05-02.
2019-05-02
20:11:26.181147 == Info: Closing connection 0
Run a minimal web server with netcat to test
while true ; do { echo -e "HTTP/1.1 201 CREATED\r\nConnection: Close\r\n\r\n"; date --iso-8601 ; } | netcat -q 0 -l 8000 ;done
I'm an ios programmer
my server gave me h264 data with TCP
but the data is not freindly like this
The startcode (00 00 00 01 or 00 00 01) is not at the start of each response data
So how can i get a whole nalu?
I'm struggling with extracting application/x-gzip HTTP responses manually because Fiddler can't extract them. For example, my Android device queries https://android.clients.google.com/fdfe/selfUpdate from time to time. The response has Content-Type: application/x-gzip and the body is only 9 bytes long (hex):
0A 03 BA 02 00 2A 02 08 00
According to the following W3C paper: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5
applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
However, GZIP should start with hex bytes 1F 8B. And according to GZIP file format, the header is always 10 bytes long so if the response body has only 9 bytes, it can't be stored as a valid GZIP file. If I store it in a file anyway, none of the following extractors can process it: gzip, arclite, 7-Zip, WinRar. As mentioned before, Fiddler can't extract it too.
Perhaps the GZIP 10-byte header was stripped - let's add it. The file contents is now:
1F 8B 08 00 00 00 00 00 00 00
0A 03 BA 02 00 2A 02 08 00
Unfortunately, this doesn't really change anything, none of the extractors mentioned above can process it.
EDIT:
Looking at a few other x-gzip responses from Google servers, the body always starts with 0x0A byte. No other similarity found.
I am trying to access a remote webservice from an asp.net application in an iis 6 server to a remote webserver.
As I wasn't able to connect, I used MS Network Monitor to look over what was happening.
This is the TLS progress
2 15:26:31 14.03.2013 0.0000000 yyy.yyy.yyy.yyy XXX.XXX.XXX.XXX TLS TLS:TLS Rec Layer-1 HandShake: Client Hello. {TLS:4, SSLVersionSelector:3, TCP:2, IPv4:1}
3 15:26:31 14.03.2013 0.0312500 XXX.XXX.XXX.XXX yyy.yyy.yyy.yyy TLS TLS:TLS Rec Layer-1 HandShake: Server Hello.; TLS Rec Layer-2 HandShake: Certificate. {TLS:4, SSLVersionSelector:3, TCP:2, IPv4:1}
4 15:26:31 14.03.2013 0.0312500 yyy.yyy.yyy.yyy XXX.XXX.XXX.XXX TLS TLS:TLS Rec Layer-1 HandShake: Certificate. Client Key Exchange. Certificate Verify.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec Layer-3 HandShake: Encrypted Handshake Message. {TLS:4, SSLVersionSelector:3, TCP:2, IPv4:1}
5 15:26:31 14.03.2013 0.0468750 XXX.XXX.XXX.XXX yyy.yyy.yyy.yyy TLS TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message. {TLS:4, SSLVersionSelector:3, TCP:2, IPv4:1}
6 15:26:31 14.03.2013 0.0781250 XXX.XXX.XXX.XXX yyy.yyy.yyy.yyy TLS TLS:TLS Rec Layer-1 Encrypted Alert {TLS:4, SSLVersionSelector:3, TCP:2, IPv4:1}
And this is final TLS transaction with the alert
- TlsRecordLayer: TLS Rec Layer-1 Encrypted Alert
ContentType: Encrypted Alert
- Version: TLS 1.0
Major: 3 (0x3)
Minor: 1 (0x1)
Length: 18 (0x12)
EncryptedData: Binary Large Object (18 Bytes)
And finaly this is the hex dump for the alert part.
15 03 01 00 12 CE CA A3 1C C9 44 5C AC A2 3C BB 3C F3 F9 8A A6 4F 22
According to http://en.wikipedia.org/wiki/Transport_Layer_Security#Alert_protocol I tried to decode the meaning
15 = 21 dec <- always 21
03 01 = major and minor Version
00 12 = lentgh
And now it gets weird. Normaly the next two bytes should be the level and description of the alert. But they make no sense. Beside that, they differ every trace I run. While the front part stays constantly the same.
Any ideas how i can decrypt the alert?
My first thought was that the other side may not allow TLS 1, while IIS 6 only supports TLS 1 (atleast that is what i thougt).
Thanks alot in advanced
The alert itself is encrypted, because the handshake was successful. So before you know what it says, you have to decrypt it - you could use ssldump, in case you have the server's private key.
Found this here: http://www.wireshark.org/lists/ethereal-users/200110/msg00055.html - after I puzzled about the same problem for a while.
This is about ssldump: http://www.rtfm.com/ssldump/
Using Wireshark, you can decrypt everything, in case you have the private key that was used for encryption: http://support.citrix.com/article/ctx116557