jm + ssl   67

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: https://news.ycombinator.com/item?id=10947186
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
Google tears Symantec a new one on its CA failure
Symantec are getting a crash course in how to conduct an incident post-mortem to boot:
More immediately, we are requesting of Symantec that they further update their public incident report with:
A post-mortem analysis that details why they did not detect the additional certificates that we found.
Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure.
We are also requesting that Symantec provide us with a detailed set of steps they will take to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. Symantec may consider this latter information to be confidential and so we are not requesting that this be made public.
google  symantec  ev  ssl  certificates  ca  security  postmortems  ops 
october 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
rwasa
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
CFSSL
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
s3.amazonaws.com "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 s3.awsamazon.com key is signed with SHA1withRSA:

https://www.ssllabs.com/ssltest/analyze.html?d=s3.amazonaws.com&s=54.231.244.0&hideResults=on

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: https://nelsonslog.wordpress.com/2015/04/28/cyberduck-is-responsible-for-my-bad-ssl-certificate/

Curl's ca-certs bundle is also used by Node: https://github.com/joyent/node/issues/8894 and doubtless many other apps and packages.

Here's a mailing list thread discussing the issue: http://curl.haxx.se/mail/archive-2014-10/0066.html -- 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
OWASP KeyBox
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
ssls.com
"Cheap SSL certs from $4.99/yr" -- apparently recommended for cheap, low-end SSL certs
ssl  certs  security  https  ops 
february 2015 by jm
Will the madness never end? Komodia SSL certificates are EVERYWHERE
I think that at this point it is safe to assume that any SSL interception product sold by Komodia or based on the Komodia SDK is going to be using the same method. What does this mean? Well, this means that those dodgy certificates aren’t limited to Lenovo laptops sold over a specific date range. It means that anyone who has come into contact with a Komodia product, or who has had some sort of Parental Control software installed on their computer should probably check to see if they are affected.
komodia  via:jgc  ssl  lenovo  parental-control  censorware  mitm 
february 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.


ouch.
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
Dan Kaminsky on Heartbleed
When I said that we expected better of OpenSSL, it’s not merely that there’s some sense that security-driven code should be of higher quality.  (OpenSSL is legendary for being considered a mess, internally.)  It’s that the number of systems that depend on it, and then expose that dependency to the outside world, are considerable.  This is security’s largest contributed dependency, but it’s not necessarily the software ecosystem’s largest dependency.  Many, maybe even more systems depend on web servers like Apache, nginx, and IIS.  We fear vulnerabilities significantly more in libz than libbz2 than libxz, because more servers will decompress untrusted gzip over bzip2 over xz.  Vulnerabilities are not always in obvious places – people underestimate just how exposed things like libxml and libcurl and libjpeg are.  And as HD Moore showed me some time ago, the embedded space is its own universe of pain, with 90’s bugs covering entire countries.

If we accept that a software dependency becomes Critical Infrastructure at some level of economic dependency, the game becomes identifying those dependencies, and delivering direct technical and even financial support.  What are the one million most important lines of code that are reachable by attackers, and least covered by defenders?  (The browsers, for example, are very reachable by attackers but actually defended pretty zealously – FFMPEG public is not FFMPEG in Chrome.)

Note that not all code, even in the same project, is equally exposed.    It’s tempting to say it’s a needle in a haystack.  But I promise you this:  Anybody patches Linux/net/ipv4/tcp_input.c (which handles inbound network for Linux), a hundred alerts are fired and many of them are not to individuals anyone would call friendly.  One guy, one night, patched OpenSSL.  Not enough defenders noticed, and it took Neel Mehta to do something.
development  openssl  heartbleed  ssl  security  dan-kaminsky  infrastructure  libraries  open-source  dependencies 
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: https://blogs.akamai.com/2014/04/heartbleed-update-v3.html -- 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.'

Ouch.
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
ImperialViolet - Apple's SSL/TLS bug
as we all know by now, a misplaced "goto fail" caused a critical, huge security flaw in versions of IOS and OSX SSL, since late 2012.

Lessons:

1. unit test the failure cases, particularly for critical security code!
2. use braces.
3. dead-code analysis would have caught this.

I'm not buying the "goto considered harmful" line, though, since any kind of control flow structure would have had the same problem.
coding  apple  osx  ios  crypto  ssl  security  goto-fail  goto  fail  unit-testing  coding-standards 
february 2014 by jm
Chartbeat's Lessons learned tuning TCP and Nginx in EC2
a good writeup of basic sysctl tuning for an internet-facing HTTP proxy fleet running in EC2. Nothing groundbreaking here, but it's well-written
nginx  amazon  ec2  tcp  ip  tuning  sysctl  linux  c10k  ssl  http 
january 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
How might the feds have snooped on Lavabit?
"I have been told that they cannot change your fundamental business practices," said Callas, who unlike Levison was able to say SilentCircle has received no NSLs or court orders of any kind. "I presume that would mean things like getting SSL keys because that would mean they could impersonate your servers. That would be like setting up a store front that says your business name and putting [government agents] in your company uniforms." Similarly, he added: "They cannot make changes to existing operating systems. They can't make you change source code." To which [Lavabit's] Levison replied: "That was always my understanding, too. That's why this is so important. Like [Callas] at SilentCircle said, the assumption has been that the government can't force us to change our business practices like that and compromise that information. Like I said, I don't hold those beliefs anymore."
ars-technica  security  privacy  nsls  ssl  silentcircle  jon-callas  crypto 
august 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 "pypi.python.org" does not match "addvocate.com". 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 addvocate.com. It's not clear at this time *why* that IP address is returning a certificate for addvocate.com.

Turned out to be a routing loop in the fast.ly 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
Lessons in website security anti-patterns by Tesco
Troy Hunt, an Aussie software architect working on a .Net security product called ASafaWeb, does a great job extensively deconstructing Tesco's appalling website security on their shopping site. In the process, he gets this wonderful tweet from their customer-care account:

"@troyhunt Let me assure you that all customer passwords are stored securely & in line with industry standards across online retailers."

As he says, this is a clear demonstration that Tesco is in the first stage of the four stages of competence -- "unconscious incompetence": "The individual does not understand or know how to do something and does not necessarily recognise the deficit." ( http://en.wikipedia.org/wiki/Four_stages_of_competence )
tesco  security  passwords  web  http  https  ssl  funny  dot-net  shopping  uk  customer-care 
july 2012 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
'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
The Monkeysphere Project
OpenPGP's web of trust extending further. 'Everyone who has used a web browser has been interrupted by the "Are you sure you want to connect?" warning message, which occurs when the browser finds the site's certificate unacceptable. But web browser vendors (e.g. Microsoft or Mozilla) should not be responsible for determining whom (or what) the user trusts to certify the authenticity of a website, or the identity of another user online. The user herself should have the final say, and designation of trust should be done on the basis of human interaction. The Monkeysphere project aims to make that possibility a reality.'
via:filippo  gpg  pki  security  software  ssh  ssl  web 
september 2011 by jm
stud
'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
Chrome to get HTTPS public key pinning
'Starting with Chrome 13, we'll have HTTPS pins for most Google properties. This means that certificate chains for, say, https://www.google.com, must include a whitelisted public key. It's a fatal error otherwise.' good anti-MITM protection
https  ssl  http  web  security  mitm  sniffing  chrome 
may 2011 by jm
Pound
'a reverse proxy, load balancer and HTTPS front-end for Web server(s). Pound was developed to enable distributing the load among several Web-servers and to allow for a convenient SSL wrapper for those Web servers that do not offer it natively. Pound is distributed under the GPL'
https  ssl  http  proxy  web  pound  reverse-proxy 
april 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 addons.mozilla.org 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
Life without a CA | The Tor Blog
do you trust the default set of root CAs in modern web browsers? sounds like we probably shouldn't
ca  certificates  https  encryption  firefox  ssl  trust  privacy  web  root-cas  from delicious
august 2010 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
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  apple  architecture  ars-technica  assembly  attacks  aws  blue-coat  book  botnets  browser  bugs  c10k  ca  cacerts  cdn  censorship  censorware  certificates  certs  china  chrome  chunked-encoding  ciphers  cloudflare  cloudfront  cnnic  coding  coding-standards  collisions  comodo  compression  crl  crls  crypto  cryptography  curl  customer-care  dan-kaminsky  ddos  debugging  defcon  dependencies  development  diffie-hellman  digicert  dot-net  drown  ebooks  ec2  ecdhe  eff  elb  elliptic-curve  encryption  end-to-end  ev  expiry  exploits  fail  fbi  filtering  firefox  flame  fraud  fridges  frontline  funny  geodns  google  goto  goto-fail  government  gpg  grades  greatfire  hacking  handshake  haproxy  hashing  heartbleed  history  holes  howto  hsdpa  http  http2  https  ilya-grigorik  inept  infrastructure  instagram  internet  ioerror  ios  iot  ip  java  javascript  jon-callas  key-length  key-lengths  keybox  komodia  latency  lenovo  libraries  lifecycle  linux  mac  mailchannels  malware  md5  microsoft  mitm  mobile  multiplexing  network  networking  nginx  nsa  nsls  nul  o2  ocsp  open-source  openssl  ops  optimization  osx  outages  owasp  packaging  packets  papers  parental-control  passwords  perfect-forward-secrecy  performance  pfs  pgp  phones  pki  plex  plugins  postmortems  poul-henning-kemp  pound  prism  privacy  private-keys  protocols  proxies  proxy  proxying  pups  pypi  python  renewal  reverse-engineering  reverse-proxy  revocation  robin-xu  root-cas  round-trip  rsa  rustock  rwasa  s3  safe-browsing  samsung  scaling  secrecy  security  security-theatre  servers  sha1  shopping  silentcircle  sniffing  snooping  software  spdy  speed  spotify  sse  ssh  ssl  ssl-labs  ssl3  sslv2  stud  superfish  surveillance  symantec  sysadmin  sysctl  tcp  tesco  testing  tests  tls  tools  tor  trust  tuning  udp  uk  unit-testing  usertrust  varnish  via:eoin-brazil  via:fanf  via:filippo  via:jgc  via:micktwomey  via:nelson  via:waxy  vulnerabilities  web  web-services  webdev  webrtc  websockets  windows  wireshark  x86_64  xhr 

Copy this bookmark:



description:


tags: