Tag Info

New answers tagged

1

PEM means Privacy Enhanced Mail, but the acronym has been long outlived by the file format. The "PEM" format is a method to encode binary data into text, so that the data may survive the transport through a medium which is text-based and not very careful with the data (typically emails). Basically, PEM begins with some header: -----BEGIN FOOBAR----- ...


0

If all you have is one .pem file to access the system then it sounds like the file contains both the certificate and the associated private key. You can verify this by opening up the file in a text editor and seeing that it contains both a "BEGIN CERTIFICATE" and a "BEGIN RSA PRIVATE KEY" section. Ideally in this situation you would have your sysadmin ...


0

The client generates the 48-byte premaster secret by concatenating the protocol version (2 bytes) and some bytes that the client generates randomly (46 bytes). The client is supposed to get these 46 bytes from a cryptographically secure PRNG; in practice, this means using the PRNG offered by the operating system (/dev/urandom, CryptGenRandom()...). The ...


2

I don't want people to send random requests to it using wget or anything similar. [...] Every copy of the app will have the (same) client certificate bundled with it. Ok, that's a bad idea. It won't work. Roughly summed up: if a secret value is copied into more than two places, then it no longer is a secret. In that case, if some people have any ...


0

Usually static resources are served from within the web root and are findable by unauthenticated users. If there's no sensitive information stored in these files (and from a security point of view I'd say that there shouldn't be) then this shouldn't really be a problem. An attacker could view the contents of the file if they can guess the URL for a valid ...


1

Hold on! Remember that if you want to use client authenticated TLS you'll need to include the private key as well as the certificate. That means the app will include a hardcoded private key and certificate. So here are a couple risks you need to consider: 1) What happens if someone reverse engineers your app and extracts the hard coded private key? 2) What ...


1

Your solution regarding authentication is fine, because it's based on mutual authentication. In case you are using Apache it can be easily achieved (after setting up the CA and client key material) by adding the following lines to the configuration: SSLVerifyClient require In order to protect your key material on the mobile phone you need to take care ...


3

You can "regenerate" the certificate on your gateway, but it will work only if you take care to reuse the same name and key. This is a certificate chain: the certificate on the gateway is the "CA certificate" and the clients have been issued certificates by that CA. Such a client certificate will be deemed valid (aka "acceptable") if whoever does the ...


1

Sorry, but the answer is "no". The top level root certificate "signs" your other certificates. When your client goes to validate their certificate, they are going to look at the signature on it, and they will see it was signed by "oldcert", they will then attempt to validate "oldcert", and discover and that "oldcert" has expired. Just having the new ...


1

Technically your certificate is not for you. You have a certificate so you can show it to other people; it is meant to convince them, not you. You don't necessarily trust your own certificate. As a safeguard against bugs, you may want to check that the public key in the certificate matches your private key: if the CA fumbled (badly) and sent you the wrong ...


0

Have a look at identity based encryption. Basically you could just use asymmetric encryption to achieve what you want. For example: encrypt everything you put on Facebook. Proof of concept: develop a plugin for Chrome which encrypts everything before it is uploaded to facebook with your private key. You spread your public key to your users. They use the ...


0

This depends entirely on what you need the application to do, exactly what data needs to be protected, and who is permitted to view the data. In the simplest case, where your application is merely an indexing system for documents and the document metadata can be stored in the clear, you can use client-side encryption to protect the document itself: the ...


1

what David said, plus make sure noone can traversal/browse your folder with static-content, either through an empty index.html inside of each folder or # apache <Directory /path/to/stuff> Options -Indexes </Directory> # nginx server { ... autoindex off; ... } sidenote / rant: when serving static content in a distributed ...


2

I wouldn't worry about it. Imagine it like this: if you use, say, django.contrib.admin, everyone knows what the admin pages look like. Is that a security risk? Not if requests are being properly authenticated and authorized. You might want to take care that the pages themselves do not expose information you'd rather keep secret or would be useful in ...



Top 50 recent answers are included