Donc le fameux VPN d'Opéra est juste un proxy https. Dans tous les cas il n'y a sans doute aucune raison saine de faire confiance à ce genre de feature qui misent sur le "sentiment de sécurité"
What animates me is knowing that we can actually change this dynamic by making strong encryption ubiquitous. We can force online surveillance to be as narrowly targeted and inconvenient as law enforcement was always meant to be. We can force ISPs to be the neutral commodity pipes they were always meant to be. On the web, that means HTTPS.
Update (2015-05-01): Since there are some common threads in the comments, we’ve put together a FAQ document with thoughts on free certificates, self-signed certificates, and more. https://blog.mozilla.org/security/files/2015/05/HTTPS-FAQ.pdf
How strong is your HTTPS connection? SSleuth ranks an established SSL/TLS connection and gives a brief summary of the cipher suite, certificate and other SSL/TLS parameters.
Ce guide va vous permettre de gagner du temps pour passer votre site web, blog, infrastructure à HTTPS, de la manière la plus propre et la plus efficace possible, laissez-vous guider !
As a web developer, I knew that using HTTPS to protect users’ sensitive data was A Very Good Idea, but I didn’t have much understanding about how it actually worked.
How's My SSL? is a cute little website that tells you how secure your TLS client is. TLS clients just like the browser you're reading this with.
How's My SSL? was originally made to help a web server developer learn what real world TLS clients were capable of. It's been expanded to give developers and the very technically-savvy a quick and easy way to learn more about the TLS tools they use.
It's also meant to impell developers to modernize and improve their TLS stacks. Many security problems come from engineers simply not knowing what worries to have. How's My SSL? is a demonstration of what those TLS client worries should be.
This is a collection of information related to the security of Secure Socket Layer (SSL) and Transport Layer Security (TLS).
The aim of this page is to keep track of the current limitations and security problems in SSL/TLS and HTTPS.
The biggest unsolved problem is the trust model of the Certification Authorities.
From now on, you should see a delightful lock next to https://konklone.com in your browser’s URL bar, because I’ve switched this site to use HTTPS. I paid $0 for the trouble.
Why you should bother doing the same:
SSL’s not perfect, but we need to make surveillance as expensive as possible
For privacy not to be suspicious, privacy should be on by default
And hey, bonus: more complete referrer information in Google Analytics for people visiting from sites already using HTTPS (like Hacker News).
This post shows how to do your part in building a surveillance-resistant Internet by switching your site to HTTPS. Though it takes a bunch of steps, each one is very simple, and you should be able to finish this in under an hour.
A quick overview: to use HTTPS on the web today, you need to obtain a certificate file that’s signed by a company that browsers trust. Once you have it, you tell your web server where it is, where your associated private key is, and open up port 443 for business. You don’t necessarily have to be a professional software developer to do this, but you do need to be okay with the command line, and comfortable configuring a web server you control.
Most certificates cost money, but at Micah Lee’s suggestion, I used StartSSL. They’re who the EFF uses, and their basic certificates for individuals are free. (They’ll ask you to pay for a higher level certificate if your site is commercial in nature.) The catch is that their website is difficult to use at first — especially if you’re new to the concepts and terminology behind SSL certificates (like me). Fortunately, it’s not actually that hard; it’s just a lot of small steps.
Below, we’ll go step by step through signing up with StartSSL and creating your certificate. We’ll also cover installing it via nginx, but you can use the certificate with whatever web server you want.
Selon les documents confiés par Edward Snowden, la NSA serait capable de déchiffrer le HTTPS et le SSL, grâce à un programme baptisé BullRun, mis au point avec son allié britannique. Des révélations à prendre avec des pincettes.
Defending yourself against the NSA, or any other government intelligence agency, is not simple, and it's not something that can be solved just by downloading an app. But thanks to the dedicated work of civilian cryptographers and the free and open source software community, it's still possible to have privacy on the Internet, and the software to do it is freely available to everyone. This is especially important for journalists communicating with sources online.
duraconf - A collection of hardened configuration files for SSL/TLS services
Hopefully this will help you make a more informed choice about what cipher list
should be used for different applications. What you find here are recommended
configurations, you should seriously consider using these, but you have to make
some choices. When you pick a cipher list, you have a couple different options
of how you go about it:
-
make a very specific declaration of what is acceptable. This has the
advantage of being able to define very closely of what you want, but the
disadvantage of having to stay on top of the latest crypto advancements, with
every crypto library upgrade. -
make a general declaration of which cipher list to use. this has the
advantage of allowing you to rely on your crypto libraries to make
(hopefully) informed choices for you (and to deactivate known
bad/weak/recently broken) ciphers while you don't have the burden of ensuring
that they are always resulting in a good cipher suite. The disadvantage is
that you cannot fine tune what exactly you get in return. -
A mixture of being specific and letting your crypto library decide from
general statements. This can be useful if, for example, you find out that
some particular crypto has become too weak, for example you might use a
generic list but then exclude MD5, because your crypto libraries haven't
removed that yet. -
Decide on a threat model for possible attacks that may expose an important
private key. Ciphers are often offered in a mode that provides Perfect
Forward Secrecy. While there are performance considerations, if you run a
high security operation where traffic disclosure would be a serious problem,
it is an important property to consider.
Generally it seems safer to have the crypto library take the bulk of the
decision since it should be for the most part fire-and-forget, while the other
options require that you always stay up to date on things and tweak as needed.
For practical use, and for people who can afford to follow crypto news, a
mixture of both is surely a good idea. So start with the general cipher list and
when you become aware that something is bad then just add this specific part to
your otherwise general cipher list until the crypto library defaults get updated
to fix that.
Unfortunately, its not possible to come up with one cipher configuration that is
going to work for all configurations. There are many different programs that
implement different versions of libraries that have different ciphers
available. In fact, a different versions of the same program may be linked
against different libraries which have different ciphers available.
An important configuration issue for service operators and users is
understanding Perfect Forward Secrecy. Generally, PFS sessions are
computationally more expensive than connections without PFS properties.
It is extremely important to remember that using SSL and/or TLS does not ensure
that your traffic is encrypted for all time. Generally, SSL/TLS services offer
two general modes of operation - one mode is ephemerally keyed and the other is not.
A TLS server that only offers AES256-SHA is strong against an attacker who will
never recovery the secret key used by the server and who cannot break AES256.
However, if an attacker is able to recover the server's key, the attacker will be able
to retroactively decrypt all traffic that has been recorded when the AES256-SHA
cipher is in use. If that same server uses an ephemeral cipher such as
DHE-RSA-AES256-SHA, the attacker cannot recover previous encrypted sesssions
without breaking RSA and/or AES256 for each session.
In both cases, when the attacker has the private key, all future communications
with the server are unsafe. Clients generally deal with this by looking up a
revokation list or by using something like the OCSP. Realistically, they're in
a lot of trouble and that kind of trouble is out of scope. If you're in doubt
it's probably a reasonable thing to use DHE or EDH modes unless you have load
issues.
The cipher lists you will find here actually vary depending on which version of
the crypto library that you have. For example, if you were to find this list
recommended:
HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH
In one version of openssl this will mean the following list of ciphers:
$ openssl ciphers -v 'HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH'
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
In a newer openssl, this list of ciphers will be different:
$ openssl ciphers -v 'HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH'
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
It is also worth noting that this is setting a policy, and your site may have
different policies, depending on your intended audience. There are many
questions to consider in determining a policy. For example, in the worst case,
when a client doesn't support the higher strength ciphers my server supports, do
I want to keep up the image that medium strength ciphers are secure enough in my
specific use case, environment and opponents? Or should I not allow anything but
the highest strength ciphers, and those clients that do not support them are
just denied? Its likely that in many cases there is no possibility of making it
clear to the user that their setup does not allow for secure use of your
services, and what their options are. I think, at least with apache, it
should be possible to redirect users whose setup doesn't provide a compatible
cipher suite, to an informational web page which explains further steps they can
and should take (i have no idea how)..
Unfortunately, in most cases, users will not get any message at all and they
will have no clue why they are shut out. This could result in unhappy users with
no idea of where to turn, and potentially a higher support burden.
Notes on format of cipher designations
Format of cipher designations differ, but in general they follow the format
described in ciphers(5). A few notes:
The order specified is the preference order, and the list is separated by
colons. The list can be specific ciphers (eg. RC4-SHA), a list of suites
containing a certain algorith (SHA1), or a cipher suite of a certain type
(TLSv1). There are also cipher strings which are a grouping of different ciphers
into a specific category (eg. HIGH).
When removing ciphers that you do not want, you have a choice between indicating
! or -, the difference is subtle but important. It's good practice to use ! if
you really do not want this class to ever get used, and to use - when you want
to allow them to be still used if you later added something to your existing
cipher list.
Finally, there is also the @STRENGTH parameter, which sorts the cipher list in
order of encryption algorithm key length.
Suggested reading
Excellent papier accompagné d'un bout de code sur github http://github.com/moserware/TLS-1.0-Analyzer/tree/master
Introducing HTTP Nowhere.
HTTP Nowhere is a Firefox browser extension I recently wrote to implement this idea. You can install it from the Firefox Add-Ons site, and check out the source at github. Beyond what is discussed above, it allows you to see which unencrypted requests were made while in this mode, and lets you add specific URLs or URL patterns to a whitelist.
This is just an initial Firefox-only implementation of the concept. I can imagine a future where the conscious action could be inserting and removing a hardware usb key to get your browser to go into this mode. This could work in concert with existing solutions that store client certificates on hardware devices.
https://addons.mozilla.org/en-US/firefox/addon/http-nowhere/
I got to wondering one day how difficult it would be to find the crypto keys used by my browser and a web server for TLS sessions. I figured it would involve a memory dump, volatility, trial and error and maybe a little bit of luck. So I started looking around and like so many things in life….all you have to do is ask. Really. Just ask your browser to give you the secrets and it will! As icing on the cake, Wireshark will read in those secrets and decrypt the data for you. Here’s a quick rundown of the steps:
Set up an environment variable called SSLKEYLOGFILE that points to a writable flat text file. Both Firefox and Chrome (relatively current versions) will look for the variable when they start up. If it exists, the browser will write the values used to generate TLS session keys out to that file.
En tout cas, la chose à retenir, c’est que tout ce que vous faîtes sur Internet est accessible. Gardez ça en mémoire, et ne tombez pas des nues quand on vous l’annonce !
This websites gives you information on the SSL cipher suites your browser supports for securing HTTPS connections.