I have gone through RFC 5766 which explains TURN protocol in detail. However, I have some fundamental questions that I am not able to figure after downloading and installing COTURN the opensource TURN server.
What is a client for a TURN server? Is it the first browser that initiates a WebRTC call? TURN servers create an allocation for the client, targeted for a specific peer. Now in WebRTC, we talk about peer to peer communication. In the RFC it talks about client-server-peer communication. All requests/responses between the client and the server are TURN-driven while those between the peer and the TURN server are just UDP data messages relayed to/from the client.
My second question is more specific to COTURN. What is the "value" field in "turn_secret" table and where/when is it used? Does the "credential" property of iceservers correspond to hmackey in the turnusers_lt table by using HMAC over (credentials, realm and username)? Where does the "value" field of "turn_secret" table figure in all this?
tl;dr: TURN secret is used to restrict the leakage of TURN credentials, it is part of TURN authentication using REST api(doc)
from coturn docs:
In WebRTC, the browser obtains the TURN connection information from the web server. This information is a secure information - because it contains the necessary TURN credentials. As these credentials are transmitted over the public networks, we have a potential security problem.
If we have to transmit a valuable information over the public network, then this information has to have a limited lifetime. Then the guy who obtains this information without permission will be able to perform only limited damage.
This is how the idea of time-limited TURN credentials appeared. This security mechanism is based upon the long-term credentials mechanism. The main idea is that the web server provides the credentials to the client, but those credentials can be used only limited time by an application that has to create a TURN server connection.
you can take a look at this answer TURN secret usage example.
Related
I've been breaking my head over how to do this, as it doesn't seem to fit any example I could find online.
My IOT device servers will run on the client network and may be accessed over it or over the open internet (with port forwarding). the device comes with a paper-printed initial pass like a router.
the client is running a mobile app.
As I hate planned obsolescence (ie, the device should keep working even if the company shuts down), I don't want to create a dependence on any third-party auth service, so the server and the app should just establish trust between themselves.
with the initial contact assumed to be trusted.
In all the examples for gPRC auth I could find, the client should somehow have ahead of time the server public key. but as there are many devices, and I want each one to have a unique cert, I don't see how I can ship the app preloaded for the specific device the user will get.
I have come up with the following:
the device generates private/public key
an insecure grpc channel serves the public key to the client
the secure grpc channel is established with that key
the client authenticates with the initial password to use the API over the secure channel
client changes the password
I'm not looking for super-max security, just basic common-sense security.
the main issue I have with the typical scheme where SSL is used to authenticate vs a domain is that I don't know via what domain/address the device would be accessed.
are there any glaring problems in the scheme? or any reason it would not work?
Thanks!
I am building up a small iot-like system, where mqtt devices(clients) are sending and receiving security-related critical information or commands.
I have got to know that TLS connection can be built optionally without client authentication thru PK certificate on the client side.
Normally, mqtt client devices don't have enough resources to support PKI, where at first it has to store a certificate and from time to time, to update it with newly issued ones when validity has passed or when the original certificate has been revoked.
That was, I think, why many of mqtt brokers have an option to configure on/off the client authentication during TLS handshake.
However, my concern is if there would be any security issue from passing the client authentication step, like, for example, a chance that some other malicious devices impersonating one of my devices can connect to the broker could obtain those critical information and commands.
My question is what best options and practices I can take to minimize that kind of risk considering the constraint resource of devices.
Missing client authentication means that everybody including an attacker can claim to be a valid client. There can be use cases like public services where this is not a problem and there are other use cases where the server wants to restrict access to specific known clients only.
There is no definitive answer to this question, it will always depend on the following factors, and only you as the designer can answer them:
What is the threat model you are working with? E.g. Who are you trying to keep out of the system and why, what are the consequences of somebody connecting a rouge client?
How much are you prepared to spend? If you intend to deploy client certificate or even a unique username/password for each device, how will it be protected? Does the hardware you intend to use support a secure enclave/hardware secret store? Meaning how hard would it be for an attacker to extract the client username/password or secret key from the device?
What other security measures do you have in place? Do you have Access Control Lists to protect which topics a client can publish/subscribe to? Do you have monitoring in place to detect malicious actions from clients so they can be disconnected and banned?
I have built a game server in nodejs using socket io.
I am planning to remove express and cookies from the authentication procedure and instead use webstorage and a client which attempts to log in during the socket io handshake.
However, I am using http and sending the user id and password in cleartext. Please, have mercy on me! I believe using https for the entire socket connection would add a huge overhead since updates are sent every 100ms. My current solution has worked for development, but I am sure it is insecure.
I should mention I have never set up/used https, so correct me if I am wrong regarding the overhead, which I know is a very debated topic. An ideal solution appears to be authenticating users over a https connection and then transmitting game state stuff over http, but I have no idea if or how this could be achieved.
Finally, I have 2 options for logging users in. I could allow the socket io connection on the server and just emit the log in credentials from the client. Then disconnect them if they are incorrect.
However, a cleaner solution would be to send the user id and pw in the http header for the handshake, and then authenticate the user from a socket.io middleware, but I am not sure if sending the data this way would be safe.
I do not think this is such a niche problem that a standard practice does not exist, however it may be to just use https. I believe there is no advantage to encrypting the users credentials as the data can still be snooped between the client and server. Any information on how I can achieve this is appreciated,
Or just point me in the right direction :)
Use one https connection for the login authentication and reply back to the client with a unique security token if the username/password is valid.
Use ordinary http connections for the rest of the dialog between client and server. Include the security token in the dialog if the client is requesting something that requires validation. Your client can store the security token in a cookie if you find that convenient, as the token can only be used for one session.
Have the server purge session tokens once a client signs off, or after the token has been idle for some period of time.
This is cheap and effective for medium-security applications. Variations on this scheme get used in many applications. It is not foolproof - a packet sniffer may be able to grab the security token in transit.
If the security token is constructed from a hash of the client IP address and a server timestamp, then it is easy for the server to validate the token in every message and very difficult for a 3rd-party to hijack the session.
I have a small device that contains a client program which communicates with a server over the internet. Pretty standard stuff.
I have a requirement that the server be able to authenticate messages coming from the device, meaning that all communications from the device be from the authentic client and not from some impostor. It's assumed that an attacker can reverse engineer the client and also load his own programs onto the device.
I'm questioning whether this is even possible. I could certainly load a client certificate into the client, but an attacker could get to this and use it himself. The cost of the device must remain low, so no fancy hardware tricks. Any ideas on how I could do this?
Depending on the device, and what kind of abuse you are talking about, you could use a scheme that needs some kind of activation. Like entering a master key into memory only - so its lost if power is lost - a technic used on some crypto cards.
A way to counter stolen devices could involve some kind of lease of keys that needs renewal on a regular basic by specifying a secret.
A way to counter an imitation/copy could be to works with a common state between the client and server that keeps changing. Like negotiating new encryption keys regularly.
We use a similar thing with our apps and web services. We call it ApiValidation where the client in each request to the service adds a header called ApiID which the server can decode to see if the client is authorized or not.
I am working on a HIPAA cloud project and am implementing a Key Store as a central repository for all of the key pairs for PHI(Private Health Information) encryption... I am not worried about the actual data because it will be encrypted at rest and in transit.
However when a worker or webrole needs to work with the data they need to decrypt and reencrypt it (if they do updates). That's where the key Store comes into play. However, I don't want this internal service exposed and I also need it to be SSLed, because sending keys in the clear, even inside a virtual network of roles wouldn't pass a security audit.
So any suggestions on how I can get a web or worker role to use SSL with an internal endpoint?
Thanks
I don't think you can. Internal endpoints are on a closed network branch, so https would normally be redundant (although I understand your compliance issues). I found this answer (to my question) very useful in figuring out the security of internal endpoints: How secure are Windows Azure internal endpoints? - see the more detailed post that Brent links to.