I came across this question and couldn't get why someone needs to digitally sign a request that is submitted over SSL
Digital Signature aims to guarantee message integrity by identifying the sender and making sure that the message is not getting altered between client and server
SSL aims to secure the communication channel between client and server to prevent sniffing and MITM attack and hence guarantees that messages cannot be altered
Can't one of the above approaches replace the other?
For example:
Over SSL, can I just rely on authentication header to identify the sender without digitally sign the request as I guarantee that SSL protects the request from MITM?
Or
Can I trust digitally signed messages over http because the server will know the source of the message and can identify if it was altered or not?
By using only SSL you guarantee that message is not altered during transmission, which is good, but it says nothing about sender, basically any client can establish ssl connection with server and send data to it.
With signature server has ability to validate not only that data was not tempered, but also that this particular client generated them.
Related
I'm making TLS client connections in Node.js. Some servers I communicate with request a client certificate. I'd like to be able to detect when this has been requested, so I can log it. At the protocol level I believe this is sent along with the TLS server hello, so the data is there, but I'm not sure how I can get at it.
I'm never actually providing a client certificate for now, I'm just aiming to report which servers requested one.
I think there's probably two cases here:
A cert has been requested, not provided, and the server has accepted the connection anyway (and then probably given my some kind of 'not authenticated' response).
A cert has been requested, not provided, and the server has rejected the TLS connection entirely.
At the moment I can't detect either case, solutions for either or both very welcome.
This question already has answers here:
With HTTPS, are the URL and the request headers protected as the request body is?
(5 answers)
Closed 8 years ago.
Say there is a client and a server. Assume the client sends a HTTP GET request GET /?secret=mysecret or GET /?token=mytoken via a) SSL and b) TLS.
SSL as I understand it is the connection is encrypted before the request details are being sent and TLS as I understand it an unencrypted request is being sent then encryption is established (maybe not).
edit: Here's an example of where my confusion is coming from: https://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https the first comment of the accepted answer.
To make the confusing perfect: SSL (secure socket layer) often refers to the old protocol variant which starts with the handshake right away and therefore requires another port for the encrypted protocol such as 443 instead of 80. TLS (transport layer security) often refers to the new variant which allows to start with an unencrypted traditional protocol and then issuing a command (usually STARTTLS) to initialize the handshake.
And that's the base reason for my question.
Anyhow my question is:
If client sends a HTTP request via a) SSL and b) TLS can the request URI be intercepted by a MITM attack aka is the interceptor able to see the request URI?
Let me rephrase the question:
Is the HTTP request sent before encryption with a) SSL and b) TLS or after encryption?
First SSL/TLS channel is built, then the request is sent. Thus the URL, as well as any other request headers, are sent encrypted.
As pointed, passing secrets in the URL is bad because the secret gets to the bookmark where it can be harvested and also to server logs (which can be undesired).
If its SSL/TLS its encryted, no body can see the request. The problem with this method is that the request is conspicuous in the browser. If somebody bookmark's the site, the secret get stored in plain text.
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).
In a TLS handshake configured with a client authentication, there is a step where the server receives the client's certificate and choose to trust it or not (for instance, in Java it is done via a TrustManager).
I would like to know if the eventual "trust failure" message from the server is sent before or after the server made sure that the client really own that public key (for example, by receiving first some messages from the handshake encoded with the client's private key).
The purpose of my question is to see if it is possible for a third party to check if the server trust a client, by pretending to be this client and by using his public key.
Note: The risk is real when TLS is used in a context with specific security requirements. For instance, let's suppose a P2P application which uses TLS between peers, and which use the TrustManager as a way to authenticate peers from his contact list. This contact list is supposed to be private. An ISP can list the IPs with who a node communicates, then get his public certificate by starting a TLS handshake with it, then he can try to connect each another nodes on the IP list. In the end, the ISP can get a big part of the contact list which was supposed to be private.
OpenSSL verifies the client certificate, too, immediately upon receiving it in the Client Certificate message.
But it is as Eugene says, if the server sends meaningful alerts, then it does not matter if you send bad_certificate right away or only after having verified the signature in the Certificate Verify message. This would only prevent someone from finding out whether a certificate is trusted or not if they additionally send a malformed signature (e.g. by using the wrong key). But if a server were implemented that way, all you had to do is sign your Certificate Verify message with a private key you just generated. Then the signature will be valid and the server will then dutifully validate the certificate you sent, revealing the same information as before.
To mitigate this situation you would really have to use a customized server that does not send the corresponding alert at all, but rather something less revealing.
This depends on implementation. Our implementation sends the error immediately, as for other implementations - I guess most do the same.
However it doesn't matter: the server sends specific error code (BadCertificate) if the certificate is not valid, so no matter when this code is sent, the attacker would know that the certificate has not been accepted. Protecting the server from this attack would require the server send a different error code and this would confuse legitimate clients.
The risk (or unpleasant consequences) of detecting that the certificate is accepted by the server or not is questionable. If this matters to you, you can change the error code and build your custom version of OpenSSL or other SSL server module you use.
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.