jm + tls   56

So much for that Voynich manuscript “solution”
The idea that the book is a medical treatise on women's health, however, might turn out to be correct. But that wasn't Gibbs' discovery. Many scholars and amateur sleuths had already reached that conclusion, using the same evidence that Gibbs did. Essentially, Gibbs rolled together a bunch of already-existing scholarship and did a highly speculative translation, without even consulting the librarians at the institute where the book resides. Gibbs said in the TLS article that he did his research for an unnamed "television network." Given that Gibbs' main claim to fame before this article was a series of books about how to write and sell television screenplays, it seems that his goal in this research was probably to sell a television screenplay of his own. In 2015, Gibbs did an interview where he said that in five years, "I would like to think I could have a returnable series up and running." Considering the dubious accuracy of many History Channel "documentaries," he might just get his wish.
crypto  history  voynich-manuscript  historians  tls 
10 days ago by jm
The hidden cost of QUIC and TOU
The recent movement to get all traffic encrypted has of course been great for the Internet. But the use of encryption in these protocols is different than in TLS. In TLS, the goal was to ensure the privacy and integrity of the payload. It's almost axiomatic that third parties should not be able to read or modify the web page you're loading over HTTPS. QUIC and TOU go further. They encrypt the control information, not just the payload. This provides no meaningful privacy or security benefits.

Instead the apparent goal is to break the back of middleboxes [0]. The idea is that TCP can't evolve due to middleboxes and is pretty much fully ossified. They interfere with connections in all kinds of ways, like stripping away unknown TCP options or dropping packets with unknown TCP options or with specific rare TCP flags set. The possibilities for breakage are endless, and any protocol extensions have to jump through a lot of hoops to try to minimize the damage.
quic  tou  protocols  http  tls  security  internet  crypto  privacy  firewalls  debugging  operability 
december 2016 by jm
Qualys SSL Server Test
pretty sure I had this bookmarked previously, but this is the current URL -- SSL/TLS quality report
ssl  tls  security  tests  ops  tools  testing 
march 2016 by jm
DROWN attack
The latest SSL security hole. 'DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.'
drown  attacks  vulnerabilities  sslv2  ssl  tls  security  holes 
march 2016 by jm
AWS Certificate Manager – Deploy SSL/TLS-Based Apps on AWS
Very nifty -- autodeploys free wildcard certs to ELBs and Cloudfront. HN discussion thread is pretty good:
ssl  tls  certificates  ops  aws  cloudfront  elb 
january 2016 by jm
How to inspect SSL/TLS traffic with Wireshark 2
turns out it's easy enough -- Mozilla standardised a debugging SSL session-key logging file format which Wireshark and Chrome support
chrome  ssl  browser  firefox  wireshark  debugging  tls 
december 2015 by jm
Designing the Spotify perimeter
How Spotify use nginx as a frontline for their sites and services
scaling  spotify  nginx  ops  architecture  ssl  tls  http  frontline  security 
october 2015 by jm
Using Samsung's Internet-Enabled Refrigerator for Man-in-the-Middle Attacks
Whilst the fridge implements SSL, it FAILS to validate SSL certificates, thereby enabling man-in-the-middle attacks against most connections. This includes those made to Google's servers to download Gmail calendar information for the on-screen display. So, MITM the victim's fridge from next door, or on the road outside and you can potentially steal their Google credentials.

The Internet of Insecure Things strikes again.
iot  security  fridges  samsung  fail  mitm  ssl  tls  google  papers  defcon 
september 2015 by jm
our full-featured, high performance, scalable web server designed to compete with the likes of nginx. It has been built from the ground-up with no external library dependencies entirely in x86_64 assembly language, and is the result of many years' experience with high volume web environments. In addition to all of the common things you'd expect a modern web server to do, we also include assembly language function hooks ready-made to facilitate Rapid Web Application Server (in Assembler) development.
assembly  http  performance  https  ssl  x86_64  web  ops  rwasa  tls 
august 2015 by jm
Cloudflare's open source CA/PKI infrastructure app
cloudflare  pki  ca  ssl  tls  ops 
june 2015 by jm
1172401 – Add Amazon root certificates
Well, well -- looks like AWS is about to disrupt PKI, and about time too. If they come up with a Plex-style "provision a cert" API, it'll be revolutionary
pki  ssl  tls  amazon  aws  apis  web-services  ops 
june 2015 by jm
How Plex is doing HTTPS for all its users
large-scale automated TLS certificate deployment. very impressive and not easy to reproduce, good work Plex!

(via Nelson)
via:nelson  https  ssl  tls  certificates  pki  digicert  security  plex 
june 2015 by jm "certificate verification failed" errors due to crappy Verisign certs and overzealous curl policies
Seth Vargo is correct. Its not the bit length of the key which is at issue, its the signature algorithm. The entire keychain for the key is signed with SHA1withRSA:

At issue is that the root verisign key has been marked as weak because of SHA1 and taken out of the curl bundle which is widely popular, and this issue will continue to cause more and more issues going forwards as that bundle makes it way into shipping o/s distributions and aws certification verification breaks.

'This is still happening and curl is now failing on my machine causing all sorts of fun issues (including breaking CocoaPods that are using S3 for storage).' -- @jmhodges

This may be a contributory factor to the issue @nelson saw:

Curl's ca-certs bundle is also used by Node: and doubtless many other apps and packages.

Here's a mailing list thread discussing the issue: -- looks like the curl team aren't too bothered about it.
curl  s3  amazon  aws  ssl  tls  certs  sha1  rsa  key-length  security  cacerts 
april 2015 by jm
Google Online Security Blog: A Javascript-based DDoS Attack [the Greatfire DDoS] as seen by Safe Browsing
We hope this report helps to round out the overall facts known about this attack. It also demonstrates that collectively there is a lot of visibility into what happens on the web. At the HTTP level seen by Safe Browsing, we cannot confidently attribute this attack to anyone. However, it makes it clear that hiding such attacks from detailed analysis after the fact is difficult.

Had the entire web already moved to encrypted traffic via TLS, such an injection attack would not have been possible. This provides further motivation for transitioning the web to encrypted and integrity-protected communication. Unfortunately, defending against such an attack is not easy for website operators. In this case, the attack Javascript requests web resources sequentially and slowing down responses might have helped with reducing the overall attack traffic. Another hope is that the external visibility of this attack will serve as a deterrent in the future.

Via Nelson.
google  security  via:nelson  ddos  javascript  tls  ssl  safe-browsing  networking  china  greatfire 
april 2015 by jm
a web-based SSH console that centrally manages administrative access to systems. Web-based administration is combined with management and distribution of user's public SSH keys. Key management and administration is based on profiles assigned to defined users.

Administrators can login using two-factor authentication with FreeOTP or Google Authenticator . From there they can create and manage public SSH keys or connect to their assigned systems through a web-shell. Commands can be shared across shells to make patching easier and eliminate redundant command execution.
keybox  owasp  security  ssh  tls  ssl  ops 
april 2015 by jm
Google delist CNNIC certs
As a result of a joint investigation of the events surrounding this incident by Google and CNNIC, we have decided that the CNNIC Root and EV CAs will no longer be recognized in Google products.
cnnic  certs  ssl  tls  security  certificates  pki  chrome  google 
april 2015 by jm
Extracting the SuperFish certificate
not exactly the most challenging reverse I've ever seen ;)
reverse-engineering  security  crypto  hacking  tls  ssl  superfish  lenovo 
february 2015 by jm
The Superfish certificate has been cracked, exposing Lenovo users to attack | The Verge
The cracked certificate exposes Lenovo users to man-in-the-middle attacks, similar to those opened up by Heartbleed. Armed with this password and the right software, a coffee shop owner could potentially spy on any Lenovo user on her network, collecting any passwords that were entered during the session. The evil barista could also insert malware into the data stream at will, disguised as a software update or a trusted site.

Amazingly stupid.
superfish  inept  ca  ssl  tls  lenovo  mitm  security 
february 2015 by jm
Superfish: A History Of Malware Complaints And International Surveillance - Forbes
Superfish, founded and led by former Intel employee and ex-surveillance boffin Adi Pinhas, has been criticised by users the world over since its inception in 2006.
superfish  lenovo  privacy  surveillance  ads  java  windows  mac  firefox  pups  ssl  tls  ad-injection  komodia 
february 2015 by jm
Why we don't use a CDN: A story about SPDY and SSL
All of our assets loaded via the CDN [to our client in Australia] in just under 5 seconds. It only took ~2.7s to get those same assets to our friends down under with SPDY. The performance with no CDN blew the CDN performance out of the water. It is just no comparison. In our case, it really seems that the advantages of SPDY greatly outweigh that of a CDN when it comes to speed.
cdn  spdy  nginx  performance  web  ssl  tls  optimization  multiplexing  tcp  ops 
january 2015 by jm
Google Online Security Blog: This POODLE bites: exploiting the SSL 3.0 fallback
Today we are publishing details of a vulnerability in the design of SSL version 3.0. This vulnerability allows the plaintext of secure connections to be calculated by a network attacker.

ssl3  ssl  tls  security  exploits  google  crypto 
october 2014 by jm
ImperialViolet - No, don't enable revocation checking
...because it doesn't stop attacks. Turning it on does nothing but slow things down. You can tell when something is security theater because you need some absurdly specific situation in order for it to be useful.
cryptography  crypto  heartbleed  ssl  security  tls  https  internet  revocation  crls 
april 2014 by jm
Akamai's "Secure Heap" patch wasn't good enough
'Having the private keys inaccessible is a good defense in depth move.
For this patch to work you have to make sure all sensitive values are stored in
the secure area, not just check that the area looks inaccessible. You can't do
that by keeping the private key in the same process. A review by a security
engineer would have prevented a false sense of security. A version where the
private key and the calculations are in a separate process would be more
secure. If you decide to write that version, I'll gladly see if I can break
that too.'

Akamai's response: -- to their credit, they recognise that they need to take further action.

(via Tony Finch)
via:fanf  cryptography  openssl  heartbleed  akamai  security  ssl  tls 
april 2014 by jm
Cloudflare demonstrate Heartbleed key extraction
from nginx. 'Based on the findings, we recommend everyone reissue + revoke their private keys.'
security  nginx  heartbleed  ssl  tls  exploits  private-keys 
april 2014 by jm
Why no SSL ? — Varnish version 4.0.0 documentation
Poul-Henning Kemp details why Varnish doesn't do SSL -- basically due to the quality and complexity of open-source SSL implementations:
There is no other way we can guarantee that secret krypto-bits do not leak anywhere they should not, than by fencing in the code that deals with them in a child process, so the bulk of varnish never gets anywhere near the certificates, not even during a core-dump.

Now looking pretty smart, post-Heartbleed.
ssl  tls  varnish  open-source  poul-henning-kemp  https  http  proxies  security  coding 
april 2014 by jm
Does the heartbleed vulnerability affect clients as severely?
'Yes, clients are vulnerable to attack. A malicious server can use the Heartbleed vulnerability to compromise an affected client.'

openssl  ssl  security  heartbleed  exploits  tls  https 
april 2014 by jm
Mark McLoughlin on Heartbleed
An excellent list of aspects of the Heartbleed OpenSSL bug which need to be thought about/talked about/considered
heartbleed  openssl  bugs  exploits  security  ssl  tls  web  https 
april 2014 by jm
"High Performance Browser Networking", by Ilya Grigorik, read online for free
Wow, this looks excellent. A must-read for people working on systems with high-volume, low-latency phone-to-server communications -- and free!
How prepared are you to build fast and efficient web applications? This eloquent book provides what every web developer should know about the network, from fundamental limitations that affect performance to major innovations for building even more powerful browser applications—including HTTP 2.0 and XHR improvements, Server-Sent Events (SSE), WebSocket, and WebRTC.

Author Ilya Grigorik, a web performance engineer at Google, demonstrates performance optimization best practices for TCP, UDP, and TLS protocols, and explains unique wireless and mobile network optimization requirements. You’ll then dive into performance characteristics of technologies such as HTTP 2.0, client-side network scripting with XHR, real-time streaming with SSE and WebSocket, and P2P communication with WebRTC.

Deliver optimal TCP, UDP, and TLS performance;
Optimize network performance over 3G/4G mobile networks;
Develop fast and energy-efficient mobile applications;
Address bottlenecks in HTTP 1.x and other browser protocols;
Plan for and deliver the best HTTP 2.0 performance;
Enable efficient real-time streaming in the browser;
Create efficient peer-to-peer videoconferencing and low-latency applications with real-time WebRTC transports

Via Eoin Brazil.
book  browser  networking  performance  phones  mobile  3g  4g  hsdpa  http  udp  tls  ssl  latency  webrtc  websockets  ebooks  via:eoin-brazil  google  http2  sse  xhr  ilya-grigorik 
october 2013 by jm
Edward Snowden's E-Mail Provider Defied FBI Demands to Turn Over SSL Keys, Documents Show
Levison lost [in secret court against the government's order]. In a work-around, Levison complied the next day by turning over the private SSL keys as an 11 page printout in 4-point type. The government called the printout “illegible” and the court ordered Levison to provide a more useful electronic copy.

Nice try though! Bottom line is they demanded the SSL private key. (via Waxy)
government  privacy  security  ssl  tls  crypto  fbi  via:waxy  secrecy  snooping 
october 2013 by jm
Good SSL for your website is absurdly difficult in practice
Yet again, security software fails on packaging and UI. via Tony Finch
security  ssl  tls  packaging  via:fanf 
september 2013 by jm
Nelson's Weblog: tech / bad / failure-of-encryption
One of the great failures of the Internet era has been giving up on end-to-end encryption. PGP dates back to 1991, 22 years ago. It gave us the technical means to have truly secure email between two people. But it was very difficult to use. And in 22 years no one has ever meaningfully made email encryption really usable. [...]

We do have SSL/HTTPS, the only real end-to-end encryption most of us use daily. But the key distribution is hopelessly centralized, authority rooted in 40+ certificates. At least 4 of those certs have been compromised by blackhat hackers in the past few years. How many more have been subverted by government agencies? I believe the SSL Observatory is the only way we’d know.

We do also have SSH. Maybe more services need to adopt that model?
ssh  ssl  tls  pki  crypto  end-to-end  pgp  security  surveillance 
august 2013 by jm
Ivan Ristić: Defending against the BREACH attack
One interesting response to this HTTPS compression-based MITM attack:
The award for least-intrusive and entirely painless mitigation proposal goes to Paul Querna who, on the httpd-dev mailing list, proposed to use the HTTP chunked encoding to randomize response length. Chunked encoding is a HTTP feature that is typically used when the size of the response body is not known in advance; only the size of the next chunk is known. Because chunks carry some additional information, they affect the size of the response, but not the content. By forcing more chunks than necessary, for example, you can increase the length of the response. To the attacker, who can see only the size of the response body, but not anything else, the chunks are invisible. (Assuming they're not sent in individual TCP packets or TLS records, of course.) This mitigation technique is very easy to implement at the web server level, which makes it the least expensive option. There is only a question about its effectiveness. No one has done the maths yet, but most seem to agree that response length randomization slows down the attacker, but does not prevent the attack entirely. But, if the attack can be slowed down significantly, perhaps it will be as good as prevented.
mitm  attacks  hacking  security  compression  http  https  protocols  tls  ssl  tcp  chunked-encoding  apache 
august 2013 by jm
Python Infrastructure Status - SSL Verification Errors on PyPI
There appears to be a problem affecting a number of users where SSL verification errors will be shown saying "" does not match "". As Best we can tell this appears to be related to the ISP. It seems to be affecting folks using O2 or O2 related companies. We've also reports of it affecting people using Free.

Cause appears to be one of the IP addresses returned in the Geo DNS for Europe returning a certificate for It's not clear at this time *why* that IP address is returning a certificate for

Turned out to be a routing loop in the London POP (via Mick Twomey)
via:micktwomey  o2  censorship  filtering  internet  ssl  tls  pypi  python  geodns  pki 
july 2013 by jm
How to secure your webapp
Locking down a webapp with current strict HTTPS policies.
It’s impossible to get to 100% security but there are steps you can take to secure your webapp for your users, to help mitigate against different types of attacks both against you, your webapp and your customers themselves. These are all things we’ve implemented with Server Density v2 to help harden the product as much as possible. These tips are in addition to security best practices such as protecting against SQL injection, filtering, session handling, and XSRF protection. Check out the OWASP cheat sheets and top 10 lists to ensure you’re covered for the basics before implementing the suggestions below.
https  ssl  security  web  webdev  tls 
july 2013 by jm
Improved HTTPS Performance with Early SSL Termination
This is a neat hack. Since SSL/TLS connection establishment requires lots of consecutive round trips before the connection is ready, by performing that closer to the user and reusing an existing region-to-region connection behind the scenes, the overall latency is greatly improved. Works for HTTP as well
http  https  ssl  architecture  aws  ec2  performance  latency  internet  round-trip  nginx  tls 
july 2013 by jm
Setting up Perfect Forward Secrecy for nginx or stud
Matt Sergeant writes up a pretty solid HOWTO:

There has been a lot of discussion recently about Perfect Forward Secrecy (PFS) and the benefits it can bring you, especially in terms of any kind of traffic sniffing attack. Unfortunately setting this up I found very few guides telling you exactly what you need to do. The downside to PFS [via ECDHE] is that it uses more CPU power than other ciphers. This is a trade-off between security and cost.
ecdhe  elliptic-curve  crypto  pfs  ssl  tls  howto  nginx  stud 
june 2013 by jm
SSL/TLS overhead
'The TLS handshake has multiple variations, but let’s pick the most common one – anonymous client and authenticated server (the connections browsers use most of the time).' Works out to 4 packets, in addition to the TCP handshake's 3, and about 6.5k bytes on average.
network  tls  ssl  performance  latency  speed  networking  internet  security  packets  tcp  handshake 
june 2013 by jm
CloudFlare, PRISM, and Securing SSL Ciphers
Matthew Prince of CloudFlare has an interesting theory on the NSA's capabilities:
It is not inconceivable that the NSA has data centers full of specialized hardware optimized for SSL key breaking. According to data shared with us from a survey of SSL keys used by various websites, the majority of web companies were using 1024-bit SSL ciphers and RSA-based encryption through 2012. Given enough specialized hardware, it is within the realm of possibility that the NSA could within a reasonable period of time reverse engineer 1024-bit SSL keys for certain web companies. If they'd been recording the traffic to these web companies, they could then use the broken key to go back and decrypt all the transactions.

While this seems like a compelling theory, ultimately, we remain skeptical this is how the PRISM program described in the slides actually works. Cracking 1024-bit keys would be a big deal and likely involve some cutting-edge cryptography and computational power, even for the NSA. The largest SSL key that is known to have been broken to date is 768 bits long. While that was 4 years ago, and the NSA undoubtedly has some of the best cryptographers in the world, it's still a considerable distance from 768 bits to 1024 bits -- especially given the slide suggests Microsoft's key would have to had been broken back in 2007.

Moreover, the slide showing the dates on which "collection began" for various companies also puts the cost of the program at $20M/year. That may sound like a lot of money, but it is not for an undertaking like this. Just the power necessary to run the server farm needed to break a 1024-bit key would likely cost in excess of $20M/year. While the NSA may have broken 1024-bit SSL keys as part of some other program, if the slide is accurate and complete, we think it's highly unlikely they did so as part of the PRISM program. A not particularly glamorous alternative theory is that the NSA didn't break the SSL key but instead just cajoled rogue employees at firms with access to the private keys -- whether the companies themselves, partners they'd shared the keys with, or the certificate authorities who issued the keys in the first place -- to turn them over. That very well may be possible on a budget of $20M/year.

Google is a notable anomaly. The company uses a 1024-bit key, but, unlike all the other companies listed above, rather than using a default cipher suite based on the RSA encryption algorithm, they instead prefer the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) cipher suites. Without going into the technical details, a key difference of ECDHE is that they use a different private key for each user's session. This means that if the NSA, or anyone else, is recording encrypted traffic, they cannot break one private key and read all historical transactions with Google. The NSA would have to break the private key generated for each session, which, in Google's case, is unique to each user and regenerated for each user at least every 28-hours.

While ECDHE arguably already puts Google at the head of the pack for web transaction security, to further augment security Google has publicly announced that they will be increasing their key length to 2048-bit by the end of 2013. Assuming the company continues to prefer the ECDHE cipher suites, this will put Google at the cutting edge of web transaction security.

2048-bit ECDHE sounds like the way to go, and CloudFlare now support that too.
prism  security  nsa  cloudflare  ssl  tls  ecdhe  elliptic-curve  crypto  rsa  key-lengths 
june 2013 by jm
Analyzing Flame's MD5 Collision Attack [slides, PDF]
really detailed slide deck by Alex Sotirov, Co-Founder and Chief Scientist, Trail of Bits, Inc. (via Tony Finch) Plenty of security fail by MS, and also: PKI is clearly too hard
via:fanf  flame  security  malware  md5  collisions  hashing  pki  tls  ssl  microsoft 
june 2012 by jm
'Convergence is a secure replacement for the Certificate Authority System. Rather than employing a traditionally hard-coded list of immutable CAs, Convergence allows you to configure a dynamic set of Notaries which use network perspective to validate your communication.
Convergence allows you to choose who you want to trust, rather than having someone else's decision forced on you. You can revise your trust decisions at any time, so that you're not locked in to trusting anyone for longer than you want.'
ssl  tls  trust  security  https  web  via:filippo  firefox  plugins  pki 
september 2011 by jm
'a network proxy that terminates TLS/SSL connections and forwards the unencrypted traffic to some backend. It's designed to handle 10s of thousands of connections efficiently on multicore machines.'
stud  tls  ssl  security  networking  web  proxies  performance 
july 2011 by jm
SSL perf tip
don't use Diffie-Hellman ciphers, they're slow
ssl  tls  nginx  performance  web  diffie-hellman  ciphers 
july 2011 by jm
ImperialViolet - Revocation doesn't work
OCSP doesn't work -- the browser vendors have failed to implement it safely
security  ssl  https  tls  ocsp  revocation  crl  via:fanf  from delicious
march 2011 by jm
Comodo's incident report on the March 15 incident
pointing the finger at the Iranian state; various login URLs for GMail, Yahoo! Mail, Hotmail, and something called "global trustee" (wtf)
security  fraud  comodo  fail  ssl  tls  ocsp  revocation  from delicious
march 2011 by jm
Detecting Certificate Authority compromises and web browser collusion | The Tor Blog
'If I had to make a bet, I'd wager that an attacker was able to issue high value [SSL] certificates, probably by compromising [the USERTRUST SSL certificate authority] in some manner, this was discovered sometime before the revocation date, each certificate was revoked, the vendors notified, the patches were written, and binary builds kicked off - end users are probably still updating and thus many people are vulnerable to the failure that is the CRL and OCSP method for revocation.' It seems was one of the bogus certs acquired. Major ouch. Thanks to EFF/Tor et al for investigating this -- SSL cert revocation is a shambles
security  ssl  tls  certificates  ca  revocation  crypto  exploits  eff  tor  comodo  usertrust  from delicious
march 2011 by jm
Overclocking SSL
techie details from Adam Langley on how Google's been improving TLS/SSL, with lots of good tips. they switched in January to HTTPS for all Gmail users by default, without any additional machines or hardware
certificates  encryption  google  https  latency  speed  ssl  tcp  tls  web  performance  from delicious
july 2010 by jm
Internet Security is a failure
ASF's Paul Querna: 'Security on the Internet sucks, and it is only getting worse. The problem is systemic, with security researchers and developers not producing viable ways for the average user to live on the Internet in a secure fashion without excessive paranoia.'
asf  authentication  infrastructure  tls  internet  security  from delicious
april 2010 by jm
TLS-encrypted spam
the Rustock botnet is now attempting TLS encryption of spam delivery sessions
tls  rustock  botnets  anti-spam  mailchannels  ssl  encryption  from delicious
march 2010 by jm
SSL trick certificate published
ioerror published the '\00' wild-card SSL cert for any domain (for affected SSL client libs at least)
ssl  tls  security  nul  ioerror  bugs  exploits  from delicious
november 2009 by jm
Public SSL Server Database
'an online service that enables you to look up the configuration of any public SSL web server. The configuration of known public SSL web servers will be periodically inspected and the results recorded. This service relies on the SSL Server Rating guide for the assessment'
ssl  grades  security  tls  https  servers  sysadmin  ssl-labs 
july 2009 by jm

related tags

3g  4g  ad-injection  ads  akamai  amazon  anti-spam  apache  apis  architecture  asf  assembly  attacks  authentication  aws  blue-coat  book  botnets  browser  bugs  ca  cacerts  cdn  censorship  certificates  certs  china  chrome  chunked-encoding  ciphers  cloudflare  cloudfront  cnnic  coding  collisions  comodo  compression  crl  crls  crypto  cryptography  curl  ddos  debugging  defcon  diffie-hellman  digicert  drown  ebooks  ec2  ecdhe  eff  elb  elliptic-curve  encryption  end-to-end  exploits  fail  fbi  filtering  firefox  firewalls  flame  fraud  fridges  frontline  funny  geodns  google  government  grades  greatfire  hacking  handshake  haproxy  hashing  heartbleed  historians  history  holes  howto  hsdpa  http  http2  https  ilya-grigorik  inept  infrastructure  internet  ioerror  iot  java  javascript  key-length  key-lengths  keybox  komodia  latency  lenovo  mac  mailchannels  malware  md5  microsoft  mitm  mobile  multiplexing  network  networking  nginx  nsa  nul  o2  ocsp  open-source  openssl  operability  ops  optimization  owasp  packaging  packets  papers  perfect-forward-secrecy  performance  pfs  pgp  phones  pki  plex  plugins  poul-henning-kemp  prism  privacy  private-keys  protocols  proxies  proxying  pups  pypi  python  quic  reverse-engineering  revocation  robin-xu  round-trip  rsa  rustock  rwasa  s3  safe-browsing  samsung  scaling  secrecy  security  security-theatre  servers  sha1  snooping  spdy  speed  spotify  sse  ssh  ssl  ssl-labs  ssl3  sslv2  stud  superfish  surveillance  symantec  sysadmin  tcp  testing  tests  tls  tools  tor  tou  trust  udp  usertrust  varnish  via:eoin-brazil  via:fanf  via:filippo  via:micktwomey  via:nelson  via:waxy  voynich-manuscript  vulnerabilities  web  web-services  webdev  webrtc  websockets  windows  wireshark  x86_64  xhr 

Copy this bookmark: