Not a lie: I have never encountered the name Lexi before. I would have assumed it to be a made-up pseudonym. Or a reference to a post-modern sci-fi / futuristic book.
If it's short for "Alexis," which is a claim you edited out of your comment, then I'm even more confused, as that name seems to be male preferred within the US.
This conversation got really out of hand really quickly, so I've stayed out of it, but is Alexis really male-preferred? That's an honest question; I don't know. Wolfram Alpha seems to find the opposite.
Can you expand further on the problem which you see? Pinning appears to address the biggest problem with the current CA model, where any of the CAs are equally valid, by allowing you to pick the CA(s) used and, if desired, even locking it to a specific host certificate:
> To perform Pin Validation, the UA will compute the SPKI Fingerprints for each certificate in the Pinned Host's validated certificate chain, using each supported hash algorithm for each certificate. (As described in Section 2.4, certificates whose SPKI cannot be taken in isolation cannot be pinned.) The UA MUST ignore superfluous certificates in the chain that do not form part of the validating chain. The UA will then check that the set of these SPKI Fingerprints intersects the set of SPKI Fingerprints in that Pinned Host's Pinning Metadata. If there is set intersection, the UA continues with the connection as normal. Otherwise, the UA MUST treat this Pin Validation Failure as a non-recoverable error. Any procedure that matches the results of this Pin Validation procedure is considered equivalent.
Unless I'm missing something, that allows you both to limit the number of CAs which you trust and if you go to the trouble of pinning specific certificates you can even limit damage from a compromised CA.
It doesn't scale, as the above spec points out. Pinning could be used to eliminate CAs (as most people initially expect) but this isn't viable at the moment. The specification, which proposes a method to validate the certificate chain, also accomplishes very little: it's fully vulnerable to MITM attacks on the first client connection. There are also privacy concerns about storing pinning data; and a browser which is configured to clear all data at exit would not see any benefit.
It's also wrong to say that public key pinning (which addresses PKI/TLS weaknesses) makes DNSSEC redundant. I suppose the proper comparison would be to the (optional) DANE?
> It's also wrong to say that public key pinning (which addresses PKI/TLS weaknesses) makes DNSSEC redundant. I suppose the proper comparison would be to the (optional) DANE?
It wasn't so much specific to pinning as a general thought that most sites will be in the situation where they need to deploy the TLS-specific measures because they have too many clients which can't assume DNSSEC but if you're already doing that, it's not clear to me that many places would see enough additional value deploying something which is less mature and harder to manage. This is particularly a big deal for anyone who doesn't control all of their infrastructure or works at a large organization.
This error is caused by a bug[1] present on outdated versions of Linux (typically exhibited by DD-WRT and Tomato routers) and can also be fixed by upgrading to OpenWRT.
Or, if that is not an option, by creating an ip6tables rule:
ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i `nvram get wan0_ifname` -d ff02::1:ff00:0/104 -j DROP
// ==UserScript==
// @name Netflix HTML5 for Linux
// @namespace 0d0a3443-cc79-4f86-bf62-2dac581d2b3a
// @version 0.1
// @description Enables HTML5 video support for the Linux host platform
// @match *://www.netflix.com/WiPlayer?*
// @user-agent Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.68 Safari/537.36
// ==/UserScript==
The problem with in-browser password management is that the attacker does not need to escape the browser. Code injection (via XSS or a browser exploit) into a running extension is likely easier than defeating the seccomp-IPC implementation or the AppArmor/SELinux profiles which protect the system. Addons like LastPass are mainly concerned with remote server weaknesses, but nothing will protect the browser from itself.
Another opinion: It's weird loading a browser+environment for non-browser passwords (SSH, HTTP/WebDAV, etc), and it's equally weird managing the passwords separately.
Note: The Strict-Transport-Security header is ignored by the browser when your site is
accessed using HTTP; this is because an attacker may intercept HTTP connections and
inject the header or remove it. When your site is accessed over HTTPS with no
certificate errors, the browser knows your site is HTTPS capable and will honor the
Strict-Transport-Security header.
An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over
non-secure transport.
and
If an HSTS Host receives an HTTP request message over a non-secure
transport, it SHOULD send an HTTP response message containing a
status code indicating a permanent redirect, such as status code 301
(Section 10.3.2 of [RFC2616]), and a Location header field value
containing either the HTTP request's original Effective Request URI
(see Section 9 ("Constructing an Effective Request URI")) altered as
necessary to have a URI scheme of "https", or a URI generated
according to local policy with a URI scheme of "https".
I'm quite stumped why there aren't more good password tools. Pass, vim-gnupg, and SublimeGPG are all I've found. The application managers are atrocious -- not only the UIs but data format interoperability as well. Browser managers are insane.
On another note, the pass documentation recommends a filesystem layout that doesn't remember usernames. I used this scheme before going back to vim:
I connect to many SSH servers that aren't under my control. It's pretty annoying to remember an arbitrary SSH port for my own.
Binding to IPv6-only is more effective at reducing log spam: IP scanning 2^128 addresses is impractical, and scanners often cannot connect because of misconfiguration/incompatibility or lack of a routable IPv6 host address.
That was an unfortunate example. The widen() in this case is absolutely unnecessary. The author even recommends using the L prefix for UTF-16 string literals inside of Windows API calls (but not on other platforms, where wchar_t isn't UTF-16):
> Do not use _T("") or L"" literals in any place other than parameters to APIs accepting UTF-16.
Except for that, you do make a good point. It's probably better to store some strings in memory according to the platform requirements, if the program can be shown to exhibit delays caused by string conversions.
If it's short for "Alexis," which is a claim you edited out of your comment, then I'm even more confused, as that name seems to be male preferred within the US.