There is such a windows application that communications with the server through https protocol, it is an auction tool and works only several hours per month. I have captured network packets (by windows network monitor) during one auction.
I am wondering whether it is possible to mimic this client, by analyzing the the packets I collected (or any packets I could collect in future auctions). I know from this wireshark artical "Secure Socket Layer (SSL)" that it should be possible (and without much effort) to descypt the entrypted messages from server, but how? And is it possible to dectrypt the messages sent by client to server, too?
So the whole reasoning behind SSL is that third party listeners who are trying to receive and decrypt packets between your client and the server won't be able to do so. The packets that your clients send will be encrypted and the server will need the appropriate key to decrypt the message which you could then analyze using wireshark. This article does a good job of explaining how HTTPS works. To answer your questions:
Is it possible to mimic the client of a https web service
Yep, this is available in a lot of different tools. A popular tool you could implement this with is called Jmeter. This article explains how you can send HTTPS requests to your server. Once you exchange the key pairs between your client (JMeter in this case) you will be able to decrypt messages on both ends which have been sent in an encrypted format over the wire.
Please let me know if you have any questions!
Related
So tons of games are run via custom clients (call it game.exe) but must communicate to a server. How does the developer ensure that only connections from the custom client are accepted and not any other requests, say from a web browser?
Ex: I play game.exe and my requests go thought no problem. I then submit a request to that game server using my web browser or some other POST utility, but it is ignored by the game server to prevent cheating.
Is this done via secret strings that are coded into game.exe and sent with every request? It seems to vulnerable to intercept them with a packet sniffer. Same applies with a client-side SSL certificate, someone could easily find the key file in the game files and forge requests.
Typically games that are stand alone applications - with a .exe extension on Windows, for example - do not use http as their protocols, unlike web browsers.
Irrespective of the protocol used, however, games typically send credentials - often account credentials, similar to a user name and password - when the connection is established. Many games uses a persistent TCP connection, so this only had to be done when logging in to the game.
Lets assume I have a VoIP service on several servers in different location and I have clients all over world.
When client make request I should be able to reply back to my client which server to use for RTP which will use a lot of data. I believe I can do this simply by checking user IP. Probably I should choice server which have less hops between itself and client, but off cause it do not guarantee best speed or lowest delay.
Is there any API for this or how is possible to achieve this? I will not consider ping or trace-route for this.
Thank you!
You can just send an echo request from clients to all your servers and use the server from where the first answer was received. This can be a simple UDP packet and you need to make this only at first launch and remember the answer.
WebRTC traffic is encrypted using DTLS - ok. But what about traffic that's relayed over a TURN server?
I'm looking for a reliable resource which confirms that the traffic is truly end-to-end encrypted (because "end-to-end" can sometimes mean several things). So I mean
NOT that there's an "end-to-end" encryption between a peer and the TURN server.
But rather,
that it is end-to-end between the peers
such that it is not decrypted/re-encrypted on the TURN server
AND that there is no way for the TURN server to get access to the secret
I haven't been able to find a definite answer to this.
The place to look is the TURN proposed standard, RFC 5766. The standard provides a means for relaying UDP packets containing application data between a client and a peer:
Once an allocation is created, the client can send application data to the server along with an indication of to which peer the data is to be sent, and the server will relay this data to the appropriate peer. The client sends the application data to the server inside a TURN message; at the server, the data is extracted from the TURN message and sent to the peer in a UDP datagram. In the reverse direction, a peer can send application data in a UDP datagram to the relayed transport address for the allocation; the server will then encapsulate this data inside a TURN message and send it to the client along with an indication of which peer sent the data.
The highest layer that TURN parses is the UDP layer. It does not understand or modify the application data layer (in your case, the WebRTC protocol). The standard says:
An application wishing to ensure that its data is not altered or forged must integrity-protect its data at the application level.
This implies that you can integrity-protect your application data, and TURN will relay it without modification. You can also look at the details of the TURN protocol (which I won't repeat here) that show that it merely wraps and forwards application data.
Finally, the standard says this on eavesdropping:
Confidentiality for the application data relayed by TURN is best
provided by the application protocol itself, since running TURN over
TLS does not protect application data between the server and the
peer. If confidentiality of application data is important, then the
application should encrypt or otherwise protect its data. For
example, for real-time media, confidentiality can be provided by
using SRTP.
The recommendation in this excerpt is to protect confidentiality by encrypting application data with a protocol such as DTLS-SRTP, which WebRTC uses.
Because TURN does not interpret or modify application data, it doesn't add any security vulnerabilities to WebRTC application data traffic that wouldn't be present without using TURN. WebRTC data is encrypted between WebRTC endpoints.
Now, no one can guarantee that there is "no way for the TURN server to get access to the secret." A rogue TURN server could attempt a man-in-the-middle attack on your connection just as easily as anyone else who can intercept your network packets. It's only true that using a TURN relay doesn't weaken WebRTC security.
As long as DTLS is implemented and used properly and assuming the DTLS algorithms and ciphers are secure, WebRTC traffic should be secured end-to-end. Part of using any SSL-based scheme requires verifying the certificate of the other endpoint, just like HTTPS. And just like HTTPS, this will require a prior out-of-band exchange of certificate identity or use of a trusted third-party. And just like HTTPS, if certificates are not properly verified then the door will be open for a MITM attack (by anyone, not just TURN servers).
I'm developing a SIP mobile softphone, customer needs a complete hiding of SIP messages from softphones to SIP servers as VOIP calls are regionally prohibited, however using TLS connection was not sufficient since the message headers are easily recognized as a SIP message. What are the best common alternative?
what about openvpn, IPSec tunneling?
Transmitting SIP over TLS means the SIP headers will only be viewable if someone is able to compromise your TLS keys, i.e. it's highly unlikely unless some national security agency is on your case.
What you might be encountering is port 5061 being blocked since it's the default and therefore well known SIP TLS port. To get around that simply use a different port for your SIP TLS connection. As far as anyone viewing the traffic goes if it's not suing port 5061 they won't have any idea that SIP is being used in your TLS stream.
Of course you also need to consider the RTP traffic which is what will carry the audio part of the call once SIP has set it up. There are no standardised ports for RTP but some popular VoIP softswitches do use certain ranges by default. For example Asterisk uses UDP 10,000 to 20,000. To work around that you'd really need to use SRTP but that's going to be harder to set up since not that many SIP user agents and servers support it. It will also be easier to detect for someone watching your traffic since even without knowing the contents the profile of RTP packets would be detectable. Still it's likely to need a sophisticated entity monitoring your traffic to detect a VoIP call using SIP over TLS on a non-standard port and SRTP call amongst the general noise of internet traffic.
This question already has answers here:
Is a HTTPS query string secure?
(9 answers)
Closed 9 years ago.
Suppose I setup a simple php web server with a page that can be accessed by HTTPS. The URL has simple parameters, like https://www.example.com/test?abc=123.
Is it true that the parameter here in this case will be safe from people sniffing the packets? And would this be true if the server does not employ any SSL certificate?
Yes your URL would be safe from sniffing; however, one hole that is easily overlooken is if your page references any third party resources such as Google Analytics, Add Content anything, your entire URL will be sent to the third party in the referer. If its really sensitive it doesn't belong in the query string.
As for your second part of the question, you can't use SSL if you don't have a certificate on the server.
http://answers.google.com/answers/threadview/id/758002.html
HTTPS Establishes an underlying SSL
connection before any HTTP data is
transferred. This ensures that all URL
data (with the exception of hostname,
which is used to establish the
connection) is carried solely within
this encrypted connection, and is
protected from man-in-the-middle
attacks in the same way that any HTTPS
data is.
All HTTP-level transactions within an
HTTPS connection are conducted within
the established SSL session, and no
query data is transferred before the
secure connection is established.
From the outside the only data that is
visible to the world is the hostname
and port you are connecting to.
Everything else is simply a stream of
binary data which is encrypted using a
private key shared only between you
and the server.
In the example you provide your
browser would do this:
Derive
hostname (and port if present)
from URL.
Connect to host.
Check certificate (it must be 'signed'
by a known authority, applied specifically
to correct IP address and port, and be
current).
The browser and server
exchange cryptographic data and the
browser receives a private key.
The
HTTP request is made, and encrypted with
established cryptography.
HTTP response is received. Also encrypted.
HTTP is an 'Application Layer'
protocol. It is carried on top of the
secure layer. According to the SSL
specification, drawn up by Netscape,
it dictates that no application layer
data may be transmitted until a secure
connection is established - as
outlined in the following paragraph:
"At this point, a change cipher spec
message is sent by the client, and the
client copies the pending Cipher Spec
into the current Cipher Spec. The
client then immediately sends the
finished message under the new
algorithms, keys, and secrets. In
response, the server will send its own
change cipher spec message, transfer
the pending to the current Cipher
Spec, and send its finished message
under the new Cipher Spec. At this
point, the handshake is complete and
the client and server may begin to
exchange application layer data."
http://wp.netscape.com/eng/ssl3/draft302.txt
So yes. The data contained in the URL
query on an HTTPS connection is
encrypted. However it is very poor
practice to include such sensitive
data as a password in a 'GET'
request. While it cannot be
intercepted, the data would be logged
in plaintext server logs on the
receiving HTTPS server, and quite
possibly also in browser history. It
is probably also available to browser
plugins and possibly even other
applications on the client computer.
At most a HTTPS URL could be
reasonably allowed to include a
session ID or similar non-reusable
variable. It should NEVER contain
static authentication tokens.
The HTTP connection concept is most
clearly explained here:
http://www.ourshop.com/resources/ssl_step1.html
The requested URI (/test?abc=123) is sent to the web server as part of the HTTP request header and thus encrypted.
However URLs can leak in other ways, usually web browser toolbars, bookmarks, and sending links to friends. POSTing data may be more appropriate depending on the context/sensitivity of the data you're sending.
I believe an HTTPS connection requires an SSL certificate, even a self-generated one if you don't want to buy one.
Hope that helps a bit!
depends on what you mean by safe
SSL encrypts the entire HTTP request/response, so the URL in the GET portion will be encrypted. This does not stop MITM attacks and corruption of the integrity of the SSL session itself. If a non-authoritative certificate is used, this makes potential attack vectors simpler.
Are REST request headers encrypted by SSL?
Is a similar question.
The url:s will be stored both in the server logs and in the browser history so even if they aren't sniffable they are far from safe.
On the wire, yes. At the end points (browser and server) not necessarily. SSL/TLS is transport layer security. It will encrypt your traffic between the browser and the server. It is possible on the browser-side to peek at the data (a BHO for example). Once it reaches the server-side, it is available to the recipient of course and is only as secure as he treats it. If the data needs to move securely beyond the initial exchange and protected from prying eyes on the client, you should also look at message layer security.
The SSL/TSL is a Transport Layer Security, yes the data can be picked with BHO (as #JP wrote) or any add on but also with "out of browser" HTTP sniffers. They read messaging between winsock32 and the application. The encryption takes place in the winsock32 not in the browser.
Take a look (this part was taked from the page of IEinspector):
IEInspector HTTP Analyzer is such a handy tool that allows you to monitor, trace, debug and analyze HTTP/HTTPS traffic in real-time.