First and foremost: if you want security, don't use MIFARE cards. They aren't the best at security. Even if a card isn't vulnerable to something like a hardnested attack or a brute-force attack, the card's data can still be sniffed over-the-air (which will include the keys or allow keys and data to be easily recovered).
Generally, most "secure" MIFARE cards will leverage multiple systems to detect the authenticity of the card. Consider a two-phased approach:
First off, leverage the builtin sector keys. The sector keys, while six bytes of size, are surprisingly difficult to crack due to how the cards work. There's no way to "dump a hash" of a MIFARE key block, so you basically need to do the cracking over-the-air/on-card. As you're not limited to ASCII, an attacker is still limited to going through a worst-case of 281.4 trillion possible combinations of bits for a single key.
Second, leverage card state verification. There are a lot of ways to do this, but a common solution is to use the value block system to keep track of how many times the card was used. A sample process exists below.
A two-phased approach like this allows you to keep out casual users who are just trying to clone their cards to their phones without any experience. It also allows you to (somewhat) perform authentication on the readers themselves which is better than nothing. If a card is copied/compromised without the attacker knowing how the system works, a copied card can only be used once before the two cards lose sync with your server and risk one of them causing both to be deactivated.
Solutions like encrypting card data, as you mentioned, won't really do anything to stop an attacker beyond making it harder for them to read the data on the card. MIFARE blocks aren't even readable if the key isn't present, so encryption really becomes an unnecessary second step unless you're trying to protect a secret.

In this example system, you have three components: the reader, a backend authentication server, and a card. On the card, sectors 1 and 2 are used by your application's data:

Sector 1 contains a unique serial number assigned to the card. This serial number is protected by a global static key in Key B. The card is set permission mode 101 to only allow ever reads from Key B. Key A does not need to be set.
Sector 2 is a bit more complicated, as it contains two blocks. Key B should be randomly generated for each card and Key A can be ignored.

Block 0 contains a randomly-generated secret value assigned to the card on creation. Permissions are set on this block as 101 similar to the one used in Sector 1.
Block 1 leverages the Value Block feature of MIFARE cards to track the number of times the card has been used. In this case, the Value Block is initialized at value 2,147,483,647 (the maximum for a signed 32-bit number). This block has permissions set to 001 such that Key B can be used to decrement this counter.

Every time a card checks in, the following process happens:

The reader uses the static Key B for Sector 1 to grab the card's unique serial number.
The reader requests card metadata from the authorization server, which responds with:

The expected value for the card currently
Whether the card can be accepted at this reader (is this user authorized)
The (random) Key B for this card
The secret value in Sector 2 Block 0 for this card

The reader reads Sector 2 and checks the card's secret value and current counter.

If either value is wrong, the card's value block is decremented to below zero, bricking the card.
If both values are correct, the card's value block is decremented by one and the card is granted access.

The reader sends the server the card's new expected value. If the card was "bricked", it will be marked as disabled and a security alert is generated.

If additional security is required (for example, the readers can't be trusted), the readers can send the card's values back to the server for authorization. Note that this does add some (generally insignificant) delay, but it can be annoying depending on the application.
Also note that such an example system is highly dependent on everything staying online at all times. In the event that a server is unable to be reached, you may want the system to fail "safe" and grant access in certain cases. If this is to be done, readers should cache read events and then submit them once the server is back online. This would require some restructuring of the card verification system to ensure that all reads are "plausible", and would generally need to take place as a scheduled job or similar concept.
Any such system is (extremely) variable and the actual implementation details depend on how secure and usable you want such a system to be in each of the edge cases. Keep in mind that after a certain point, your return on investment into security starts to decrease and additional complication becomes complication for complication's sake.


There's no way to enforce all traffic via socks proxy. You would be better with VPN.

You can configure system to not connect to the internet if not on VPN connection, Linux for example has such tickerbox to enable it without hassle. It can also be done using firewall and routing. It depends on what OS you are using and what VPN.

Using routing for example, you configure only routing to your VPN router and do not configure default gateway. This way, default gateway is setup only on VPN connection. Also to prevent DNS leaks, you configure DNS to 8.8.8.8 so it works only via VPN default gateway. In this simple way you can do it with VPN.


Blocking DiagTrack outbound connection after malware infection

If this is a basic, fresh Windows 10 install, this is probably NOT persistent malware. This is most likely Windows Telemetry services - since Windows 8, Microsoft has been adding more and more automated "phone home" functions into their OSes - some of which are exceptionally difficult to disable. This is all related to the "Application Experience" functions of the OS (benign reasons to do this - to get performance data about the OS and applications, to determine how people use their OS. Malevolent reason to do this - data gathering, ad serving, etc)

References to this server online point to Microsoft Singapore, and there are a lot of people reporting DiagTrack as a Microsoft telemetry service and reference the same IP address that you see.

You can verify that this is a Microsoft tool by using another Microsoft tool called Process Explorer (download this from Microsoft, search for Process Explorer and SysInternals - a great suite of tools for digging into the OS). Running Process Explorer, you can view all of the running processes on your system, what company created them, and whether they are digitally signed (run Process Explorer, choose displayed columns - add Company Name and Verified Signer, then select Options - Verify Image Signatures). This will check that the running processes are coming from officially valid files from the publishers. If the image is digitally signed, it's either a good Microsoft product or Microsoft's code signing certs have been compromised and we're all in a world of hurt ;)

You can try to disable this and other Windows telemetry by opting out of the Application Experience program, but some telemetry functions continue to run in Windows 10. Another researcher proposed 'sink-holing' the telemetry traffic by blocking the routing to this IP ( http://sphughes.com/2015/09/04/block-microsoft-telemetry-using-null-routes/ ) - but of course, Microsoft would prefer that you did not do that.


injecting malicious code to existing exe file: what really happens?

When you run an executable, you're basically getting your computer to read and execute some specified sections of the file. Oversimplification:

Imagine you're reading a document. You first open the document and your reader will display the contents of the file to you. It can do this because the preceding section of the file, or its header tells it what the file is and what to do with it and also what sections are filled with valid data.

Something similar happens when you run an executable. Your computer reads the file and understands what section of the file to execute to show you some output on the screen. When msfvenom backdoors an executable, it identifies what sections of the compiled file are marked with executable data and proceeds to replace or add it's own payload (like a reverse shell script or whatever you'd like) in this place. When you send it to your victim and they run the file, their systems end up running the evil payload as it thinks it's legitimate. This sometimes does backfire though - since msfvenom has no way to see exactly what it's replacing, it sometimes replaces crucial portions like the GUI and that makes the executable look broken on execution.

You could do this yourself too. Just replace the main function of a program with your payload and it'll execute it as the normal application would.


force uploading a file to a server with an open port

As @SmokeDispenser mentioned in is comment, this is a very broad question, so the list below is very general.

Stolen Credentials - You need to be able to update the PHP files yourself, so you need to have some sort of interface to do that.  It's possible that an attacker stole those credentials and used the interface just like you did.
Remote Code Execution Bug - It's possible that your code has a bug which allows users to execute arbitrary code, and the attacker exploited this to download the file to the server.  If you are using a framework, such as Wordpress, cakePHP, etc., the bug might exist in that software.
Another with another application on the system which allowed the user to gain access to the filesystem.

The first two items are the most likely attack vectors.  Do you know the original owner of the file?  That might be the best clue as to how that file was created.


Evaluating spam score for a single page application

What happens to your database?  Think from an attacker's perspective and look for ways to abuse the system.

There are three methods a form/API can be used to spam:

The submitted data shows up on a website
The submitted data is sent via email (usually to a small and fixed set of people)
There is a vulnerability in the implementation that can be exploited to use your site to relay spam in another manner (review your code! this method is not otherwise discussed here)

If the data is shown on a website (or if an attacker makes that assumption), you're likely to see comment spam aspiring to:

Perform search engine optimization
Spread malware (by link and/or attachment)
Damage your site's credibility or otherwise provide noise
Troll you or users of your site
Spread fake news or other propaganda (essentially #4 and #1)

You can combat form→email spam and web comment spam as follows:

Use blacklists like URI DNSBLs to combat link spam
(Web only) Render links with nofollow, like this
Do not allow attaching non-media files
Rate limit:  “Too many submissions from this IP, try again later”
Limit privileges for newcomers, e.g.

“You can't attach files until …”
“You can't provide links until …”, then use nofollow, then allow fully
“You can't post images until …”
“You can't post more than once an hour until …”

Have a moderation team review every post before it goes public

(Web only) Crowdsource it! Consider a user moderation system like Discourse

Build a machine learning algorithm to automate the human moderation team
Implement a captcha (and make it harder for newcomers than for regular users)

The less visible "success" is for an attacker, the less persistent attacks will be (though some attackers don't care).  Even claiming to have moderator review but merely delaying a new user's posts by a few hours may thwart some spam.

If you're sending email, you can use one of many Bayesian systems internally to see whether you want to drop the submission from your database and/or from pushing externally.  ( You'll still have to regularly train this system.)  You may also want to use an Email Service Provider (ESP) to handle your outbound reputation for you.

You can report spam images to Knujon ("No Junk" spelled backwards) in its image-only file upload. You can report phishing landing sites to PhishTank.


Can Microsoft access the contents of my OneDrive Personal Vault?

Apparently you can unlock your Personal Vault by SMS, Email and various other methods, so Microsoft's internal systems would be able to read/decrypt your data similar to how OneDrive's regular files operate. There is also no mention about losing access to files after a password reset, which would be the case if the data was encrypted with a key that Microsoft didn't control.


The $where operator in MongoDB is a feature which is best avoided. Its performance is abysmal, and not just because it doesn't benefit from indexes. Almost every common use-case can be solved much more efficiently with a common find-query or aggregation, especially one as trivial as this. But this is security stackexchange, not stackoverflow, so let's focus on the security implications.

The $where statement passes a javascript code snippet to the database which the database will then execute once for each document in the collection. Thankfully this script has no access to the db object and other dangerous shell functions and it works on copies of the documents, so the attacker can at least not change the database content like with many SQL injections. But it is for example vulnerable to attacks where the attacker wants to return other results than intended.

Let's make up an example. Let's say we have a blog. Our blog has lots of articles which can be read public, but we also have some private articles which are for our internal use and not supposed to be published. So we have a field hidden in our documents which can be true or false depending on whether or not our visitors are supposed to see the article. Our MongoDB query to get a list of all articles in a certain category for displaying it to the website visitor looks like this:

db.articles.find({"$where": "this.hidden == false && this.category == '"+category+"'" });

That should make sure nobody looks at our hidden articles. Or does it? When the user controls the category-variable, they can set it to this string:

'; return '' == '

The resulting Javascript snippet which gets send to the database is this:

this.hidden == false && this.category == ''; return '' == ''

When you have a javascript snippet with multiple commands separated by ;, they will be executed as a function and a return statement is needed to determine which value will be passed back to the caller. This function will always return true. That means the user will also see all articles in our collection, including those which are supposed to be hidden.


What's the difference between SSL, TLS, and HTTPS?

TLS is the new name for SSL. Namely, SSL protocol got to version 3.0; TLS 1.0 is "SSL 3.1". TLS versions currently defined include TLS 1.1 and 1.2. Each new version adds a few features and modifies some internal details. We sometimes say "SSL/TLS".

HTTPS is HTTP-within-SSL/TLS. SSL (TLS) establishes a secured, bidirectional tunnel for arbitrary binary data between two hosts. HTTP is a protocol for sending requests and receiving answers, each request and answer consisting of detailed headers and (possibly) some content. HTTP is meant to run over a bidirectional tunnel for arbitrary binary data; when that tunnel is an SSL/TLS connection, then the whole is called "HTTPS".

To explain the acronyms:

"SSL" means "Secure Sockets Layer". This was coined by the inventors of the first versions of the protocol, Netscape (the company was later bought by AOL).
"TLS" means "Transport Layer Security". The name was changed to avoid any legal issues with Netscape so that the protocol could be "open and free" (and published as a RFC). It also hints at the idea that the protocol works over any bidirectional stream of bytes, not just Internet-based sockets.
"HTTPS" is supposed to mean "HyperText Transfer Protocol Secure", which is grammatically unsound. Nobody, except the terminally bored pedant, ever uses the translation; "HTTPS" is better thought of as "HTTP with an S that means SSL". Other protocol acronyms have been built the same way, e.g. SMTPS, IMAPS, FTPS... all of them being a bare protocol that "got secured" by running it within some SSL/TLS.


You can find many examples of backup rotation schemes, like here:

http://www.backupassist.com/education/bsg2.html

We keep (at work) backups for the last 30 days, but that wouldn't solve this problem. It could well be that we are infected for two months without noticing it. In that case: remove by hand or reinstall.

When you use VMs like Amazon EC2, you can use snapshots. For your server or desktop OS, you can make a snapshot or image (disk image on tape or harddisk) of the installation right after initial setup, and right after all configuration is done, but without data. Later you can go back to that image. I use this method for creating vms for local development and testing machines.

You need to test backups on a regular basis. Do they still work? Do they still backup what is needed? Has the situation changed with new servers or data drives so you need to add or remove them from the backup scheme? And have you ever tested if you can restore a backup successfully? That takes time and effort, and you may postpone that, but you need it you better have a good procedure.

Another tip is to use two different backup methods, like one with tape, another in the cloud or using another backup program. For my laptop I use Time Machine and Crashplan.

None of these tips can make it so that nothing ever will be lost.

Sometimes you (or a process) delete(s) a folder without noticing it, and years later you need something in it, and it is simply gone. Once I deleted a mail account in my mail app, not realizing that this deleted sent mails. It tooks several years before I found out, and it was lost. I've had several times that I deleted something on my laptop that I needed later, and sometimes the backups saved me, but not always.

On my desktop I use Crashplan, which can backup everything and can save different versions of documents. But do realize that such a service can go bankrupt and then your backups are lost. You can use this program for local backups, but it seems to be that local restores won't work when CP is offline. So when they go bankrupt the local backups are gone too! Still it's a great service I think.


This flaw should be graded by capability and exploitability.

Capability falls into the following categories:

The ability to alter information on the system that you should not be able to.
The ability to view information on the system that you should not be able to, such that a person's personal information is revealed, or credentials (or other items of information) are leaked that may aid an attacker in gaining further access to the system.
The ability to view incidental information on the system that you should not be able to, e.g. the sum of the prices of items in another user's basket on an e-commerce site.
No ability.

Exploitability falls into the following categories:

Trivially exploitable in a reliable manner, e.g. admin's user is always ID 1, or users are always given sequential IDs.
Moderately difficult to exploit, e.g. having to search through a sequence of 24-bit integers for potential identifiers.
Difficult to exploit, e.g. computing Gn+1 from G0..n, where G is a poor quality random number generator.
Impossible* to exploit, e.g. the problem equates to brute forcing a 128-bit keyspace. (* impossible = highly improbable, and way outside the cost/benefit ratio for attackers)

Note that this is not an integer scale - feel free to rate something as, for example, a 2.5 in capability.

The trick is that without exploitability, capability is pointless, and without capability, exploitability is meaningless.

In order to grade this, consider the above points, and compare your ratings to the importance of the protected resource. Also remember that sequential IDs make development easy, so the risk analysis should take this into account.

As a rule of thumb, if you're looking at anything worth protecting, and the mean average of the two numbers is less than 2, call it a high. If it's greater than two, it's entirely subjective.

I also suggest you take a look at the Common Vulnerability Scoring System (CVSS) and NVD's CVSSv2 calculator, which does a great job of demonstrating vulnerability assessment and scoring.


Is it possible to maintain security and data integrity through a network decrypting HTTPS?

SSL in the context of web browsing allows you to create a secured (encrypted) tunnel between your browser and a SSL-enabled endpoint.

The SSL-enabled endpoint is typically the server you want to reach, but as you mention in your question, you may have a HTTPS decrypting proxy on the way. This proxy terminates your SSL connection (it is therefore in clear from that point, analyses it, and then creates an SSL tunnel with the target server.

What this mean is that during the time your connection is decrypted everything you send can be read.

This "everything" can be plaintext data (like a password for instance) or whatever you push though this connection (an encrypted file for instance). You could also build a "tunnel in tunnel" of sorts: an ssh connection which can act as a proxy forwarding a local port on your machine to a port on a target server. The HTTPS connection is decrypted by your HTTPS proxy, but the ssh one remains.

I do not know whether you are asking the question from the perspective of someone who has to go though such a proxy, or someone who puts such a proxy in place. If the latter - be very much aware of the potential legal consequences. Your local law may not allow that, or you may be held liable for anything which goes wrong during the decryption phase.


I've seen implemented a similar pattern - where a number of "originating" IAM solutions that was where users "lived" where mapped to an external supplier (in this case, a Salesforce based app), by creating a single "externally visible" IDP.

The advantages of this approach are several:

The biggest one, the external suppliers are simpler to configure and maintain as they don't have to add "n" external IDPs (if they support having more than one IDP for a given customer/tenant!!!)
The security of the service offered by the supplier is enhanced, as there's a single point for configuration/validation (vs having 5 "peer" trust sources that open up 5x the potential attack surface)
The "source" IAM systems don't have to be exposed externally as only one "visible" IDP is created
The "bridge" IDP/IAM solution can apply transforms and enforce a consistent set of claims and attributes that are exposed to the external suppliers, without needing to re-configure the source systems. This makes easier to adopt to changes in the suppliers, or to different requirements in the suppliers federation config.
You can also do protocol transformation. In the case I'm familiar with, the left-hand internal IAM systems were using a mix of SAML and OIDC, while the outgoing federation was using OIDC
Specific to this implementation, but not strictly needed, the "New IAM" solution included a user repository and a unified/centralized identity per "real" user was created for the users in the "source" IAM systems; a given living user could have different accounts in the different source IAMs, and the objective was to ensure that the externally visible account was the same, regardless of how the user was logged-on internally...

The way this worked was, the "New IAM" solution was configured to act as an SP for the left hand "source" IAM systems, that were acting as IDPs. The "incoming" federation request was validated, the specific policies configured in the NewIAM stack for access and transformation are checked, and if all matches, the user is redirected to the external supplier. The external supplier is configured to query the "New IAM" solution, that in this case acts as IDP.

It sounds somewhat convoluted, but it's simpler in practice than it sounds... the system is working fine, and orchestrating ~5 M users and expecting bigger growth.

Hope this helps!!


Has the leaked D-Link Windows signing key been revoked?

Update 2016-12-28: I finally decided to check the CRL as well. And it turns out: Yup, certificate is in there still. Even long after its original expiration date.

$ openssl x509 -in 0.dlink.cer -noout -fingerprint | sed 's/://g'
SHA1 Fingerprint=3EB44E5FFE6DC72DED703E99902722DB38FFD1CB

$ openssl x509 -in 0.dlink.cer -noout -serial
serial=5067339614C5CC219C489D40420F3BF9

$ openssl x509 -in 0.dlink.cer -noout -text | grep CRL -A3 | grep URI | sed 's/^ *URI://'
http://csc3-2010-crl.verisign.com/CSC3-2010.crl

$ openssl x509 -in 0.dlink.cer -noout -text | grep CRL -A3 | grep URI | sed 's/^ *URI://' | xargs -- wget -q --

$ sha256sum CSC3-2010.crl
529d1b6a0588d91bf2f8dc25e35b52d54f2865499d2d4fd6153f488bb1e90e73 *CSC3-2010.crl

$ openssl crl -inform der -in CSC3-2010.crl -noout -text | grep -A1 "Serial Number: 5067"
    Serial Number: 5067339614C5CC219C489D40420F3BF9
        Revocation Date: Sep  3 00:00:00 2015 GMT

Further info on pastebin: CRL snapshot PEM format, CRL snapshot parsed text format.

Update 2016-09-29, 2/2: If you wish to try the openssl ocsp command for yourself: I have put the D-Link certificates and the verbose OCSP output on PasteBin.

Update 2016-09-29, 1/2: Coming back to this post a year later, I checked VirusTotal and, yes, they now list the file signature as revoked under the "File detail" tab. (But I don't know when exactly in the last 11 months that happened.)

Update 2015-10-02: Related question: Did D-Link's certificate revocation really only invalidate 1 day (of a six months long exposure)?

Update 2015-09-25. Revoked now.

OCSP via OpenSSL yields "revoked"

$ openssl ocsp -issuer 1.intermediate.verisign.cer -CAfile <(cat 1.intermediate.verisign.cer 2.root.verisign.cer) -cert 0.dlink.cer  -url http://ocsp.verisign.com
WARNING: no nonce in response
Response verify OK
0.dlink.cer: revoked
        This Update: Sep 24 19:26:52 2015 GMT
        Next Update: Nov  7 03:08:53 2015 GMT
        Reason: keyCompromise
        Revocation Time: Sep  3 00:00:00 2015 GMT

Weird Revocation Time

Timeline for perspective:

Jul  5 00:00:00 2012 GMT. Validity: Not Before
Feb 27          2015      Inadvertent disclosure
--- six months of nothing ---
Sep  3 00:00:00 2015 GMT. OCSP "revocationTime" backdated to this.
--- one day of invalidity (?) ---
Sep  3 23:59:59 2015 GMT. Validity: Not After
Sep 17          2015      Tweakers.net report
Sep 18          2015      TheRegister.co.uk report
Sep 20 14:00    2015      This question here posted.
Sep 20          2015      Answer posted. OCSP `good`
Sep 22          2015      Update answer posted. OCSP `revoked`

So: OCSP revocationTime is 2015-09-03. But when I checked on 2015-09-20 it was still good. So this seems backdated. (Correct me if I'm wrong.)

So if you backdate at all, then why not backdate directly to 2015-02-27? Does this even matter?

Microsoft blacklisted

Microsoft Security Advisory 3097966, 2015-09-24, Inadvertently Disclosed Digital Certificates Could Allow Spoofing

  Microsoft is aware of four digital certificates that were inadvertently disclosed by D-Link Corporation that could be used in attempts to spoof content. The disclosed end-entity certificates cannot be used to issue other certificates or impersonate other domains, but could be used to sign code. This issue affects all supported releases of Microsoft Windows.

VirusTotal still good.

Reason unknown. Might be because of the weird revocationTime.

Old messages below.

No. OCSP is still "good".

No longer valid. See 2015-09-25 update.
OCSP says it's still "good". CRL, I don't know. (And I didn't try CRL either.) CRL isn't supposed to (or mustn't ?) list any certificate that's already expired. And that D-Link cert expired about two weeks ago.

Checking with OpenSSL

$ openssl ocsp -issuer 1.intermediate.verisign.cer -CAfile <(cat 1.intermediate.verisign.cer 2.root.verisign.cer) -cert 0.dlink.cer  -url http://ocsp.verisign.com
WARNING: no nonce in response
Response verify OK
0.dlink.cer: good
    This Update: Sep 19 11:43:51 2015 GMT
    Next Update: Sep 26 11:43:51 2015 GMT

Checking with VirusTotal.com

Here's a sample file that was signed with that particular D-Link certificate:

https://www.virustotal.com/en/file/c25988e924a91a262029d8786c888bbc318d1500ddbd83e1cbe8c7e82f84e292/analysis/

VirusTotal screenshot

And as of now (2015-09-20) it still says "Valid" under File Details | Signers | [+] D-LINK CORPORATION | Status

I guess this status might change in the next few weeks.
Then it should say Signature verification:  A certificate was explicitly revoked by its issuer. Like these two certs here for example:

VirusTotal: Revoked Bit9 cert
VirusTotal: Revoked Samsung cert

Chain members

If you want to check yourself, below are the files I used.

0.dlink.cer

This is the certificate with the Serial Number and SHA1 hash that match with the screenshots in the Tweakers.net article.

$ openssl x509 -in 0.dlink.cer -noout -fingerprint
SHA1 Fingerprint=3E:B4:4E:5F:FE:6D:C7:2D:ED:70:3E:99:90:27:22:DB:38:FF:D1:CB

$ openssl x509 -in 0.dlink.cer -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            50:67:33:96:14:c5:cc:21:9c:48:9d:40:42:0f:3b:f9
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Code Signing 2010 CA
        Validity
            Not Before: Jul  5 00:00:00 2012 GMT
            Not After : Sep  3 23:59:59 2015 GMT
        Subject: C=TW, ST=Taipei, L=TAIPEI CITY, O=D-LINK CORPORATION, OU=Digital ID Class 3 - Microsoft Software Validation v2, CN=D-LINK CORPORATION
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e2:d5:cc:02:33:47:16:ea:79:bc:51:39:ae:c3:
                    f6:96:f6:43:73:68:6c:35:83:58:63:f6:46:d8:56:
                    48:df:48:fd:bd:b0:a6:0c:59:10:20:89:c0:cc:73:
                    59:2f:8c:1a:5a:fc:15:b7:b8:de:cc:4e:1b:3f:50:
                    4c:98:bb:53:33:fc:7b:13:15:b1:b5:c0:5d:97:95:
                    81:ab:9c:2d:0a:3c:e5:14:0d:03:3d:cd:6e:43:9c:
                    0a:75:04:00:b8:50:32:12:ba:9e:6f:ac:fe:93:c7:
                    93:53:c9:98:29:71:dc:85:fc:23:ef:8c:4a:6a:e7:
                    b9:c7:47:af:58:73:cb:29:e1:3b:ac:c9:55:71:89:
                    4c:d6:0a:7c:70:dc:bc:cb:f0:b4:dd:25:ec:72:96:
                    86:36:86:09:1c:c7:ba:5f:a4:37:2d:42:f0:ae:00:
                    fb:5d:97:52:ed:c6:e0:d5:bd:2f:71:fe:98:f6:b4:
                    40:d1:67:61:0a:41:ce:a2:32:6d:ce:90:d9:5f:09:
                    df:b3:c8:f9:8c:da:33:89:42:8d:72:1e:a2:39:c7:
                    2a:2d:b0:a3:91:aa:8a:e9:a9:e6:ab:24:7b:62:d2:
                    9b:35:22:0f:46:1c:87:8b:af:e1:19:98:b4:bd:cf:
                    6d:4c:c4:04:7f:cf:a1:dd:47:71:d8:fb:eb:33:3e:
                    09:d9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://csc3-2010-crl.verisign.com/CSC3-2010.crl

            X509v3 Certificate Policies:
                Policy: 2.16.840.1.113733.1.7.23.3
                  CPS: https://www.verisign.com/rpa

            X509v3 Extended Key Usage:
                Code Signing
            Authority Information Access:
                OCSP - URI:http://ocsp.verisign.com
                CA Issuers - URI:http://csc3-2010-aia.verisign.com/CSC3-2010.cer

            X509v3 Authority Key Identifier:
                keyid:CF:99:A9:EA:7B:26:F4:4B:C9:8E:8F:D7:F0:05:26:EF:E3:D2:A7:9D

            Netscape Cert Type:
                Object Signing
            1.3.6.1.4.1.311.2.1.27:
                0.......
    Signature Algorithm: sha1WithRSAEncryption
         eb:4e:60:57:88:d5:ce:77:a1:94:32:9b:68:fd:3c:23:c4:06:
         fc:43:2e:d6:66:8c:9d:6d:7a:03:07:fb:7b:66:24:3b:30:99:
         9b:d1:3d:66:a9:ca:95:f0:e3:1c:e0:6b:45:03:51:f4:64:15:
         e8:8e:7a:98:17:8c:c0:95:56:58:55:54:ae:54:5d:8f:e2:65:
         0e:cd:79:17:87:0e:8a:2e:40:de:2e:1c:35:5b:6e:ea:23:5a:
         4d:70:8e:1d:05:c0:04:d6:2d:c1:26:80:cf:0f:f8:b6:84:4c:
         eb:82:44:c4:03:f0:65:9e:33:43:f0:e7:39:73:30:be:51:11:
         e8:70:b3:c3:48:77:fd:d2:e0:8f:fe:dd:89:27:b5:b0:31:ac:
         57:63:9d:29:68:9d:2a:8e:e4:d0:dd:5e:d0:6d:f3:bf:63:4d:
         fa:76:ff:f8:ad:a8:29:c9:90:32:f4:31:22:32:b8:67:92:00:
         15:3f:ae:cd:27:71:c2:01:80:24:52:09:6c:14:63:0b:c0:b6:
         69:16:5c:d4:34:a4:40:b0:c6:b6:c3:90:ef:64:fc:a8:b2:eb:
         d8:57:68:43:47:21:55:88:2b:f3:f8:e7:84:52:75:17:73:0c:
         8f:86:f7:b1:ea:66:4e:c5:47:7c:27:13:d0:f4:c7:c6:8a:8a:
         f0:df:d9:a5
-----BEGIN CERTIFICATE-----
MIIFazCCBFOgAwIBAgIQUGczlhTFzCGcSJ1AQg87+TANBgkqhkiG9w0BAQUFADCB
tDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEuMCwGA1UEAxMl
VmVyaVNpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgMjAxMCBDQTAeFw0xMjA3MDUw
MDAwMDBaFw0xNTA5MDMyMzU5NTlaMIGuMQswCQYDVQQGEwJUVzEPMA0GA1UECBMG
VGFpcGVpMRQwEgYDVQQHEwtUQUlQRUkgQ0lUWTEbMBkGA1UEChQSRC1MSU5LIENP
UlBPUkFUSU9OMT4wPAYDVQQLEzVEaWdpdGFsIElEIENsYXNzIDMgLSBNaWNyb3Nv
ZnQgU29mdHdhcmUgVmFsaWRhdGlvbiB2MjEbMBkGA1UEAxQSRC1MSU5LIENPUlBP
UkFUSU9OMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4tXMAjNHFup5
vFE5rsP2lvZDc2hsNYNYY/ZG2FZI30j9vbCmDFkQIInAzHNZL4waWvwVt7jezE4b
P1BMmLtTM/x7ExWxtcBdl5WBq5wtCjzlFA0DPc1uQ5wKdQQAuFAyErqeb6z+k8eT
U8mYKXHchfwj74xKaue5x0evWHPLKeE7rMlVcYlM1gp8cNy8y/C03SXscpaGNoYJ
HMe6X6Q3LULwrgD7XZdS7cbg1b0vcf6Y9rRA0WdhCkHOojJtzpDZXwnfs8j5jNoz
iUKNch6iOccqLbCjkaqK6anmqyR7YtKbNSIPRhyHi6/hGZi0vc9tTMQEf8+h3Udx
2PvrMz4J2QIDAQABo4IBezCCAXcwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCB4Aw
QAYDVR0fBDkwNzA1oDOgMYYvaHR0cDovL2NzYzMtMjAxMC1jcmwudmVyaXNpZ24u
Y29tL0NTQzMtMjAxMC5jcmwwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgG
CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMBMGA1UdJQQM
MAoGCCsGAQUFBwMDMHEGCCsGAQUFBwEBBGUwYzAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMDsGCCsGAQUFBzAChi9odHRwOi8vY3NjMy0yMDEw
LWFpYS52ZXJpc2lnbi5jb20vQ1NDMy0yMDEwLmNlcjAfBgNVHSMEGDAWgBTPmanq
eyb0S8mOj9fwBSbv49KnnTARBglghkgBhvhCAQEEBAMCBBAwFgYKKwYBBAGCNwIB
GwQIMAYBAQABAf8wDQYJKoZIhvcNAQEFBQADggEBAOtOYFeI1c53oZQym2j9PCPE
BvxDLtZmjJ1tegMH+3tmJDswmZvRPWapypXw4xzga0UDUfRkFeiOepgXjMCVVlhV
VK5UXY/iZQ7NeReHDoouQN4uHDVbbuojWk1wjh0FwATWLcEmgM8P+LaETOuCRMQD
8GWeM0Pw5zlzML5REehws8NId/3S4I/+3YkntbAxrFdjnSlonSqO5NDdXtBt879j
Tfp2//itqCnJkDL0MSIyuGeSABU/rs0nccIBgCRSCWwUYwvAtmkWXNQ0pECwxrbD
kO9k/Kiy69hXaENHIVWIK/P454RSdRdzDI+G97HqZk7FR3wnE9D0x8aKivDf2aU=
-----END CERTIFICATE-----

1.intermediate.verisign.cer

$ openssl x509 -in 1.intermediate.verisign.cer -noout -fingerprint
SHA1 Fingerprint=49:58:47:A9:31:87:CF:B8:C7:1F:84:0C:B7:B4:14:97:AD:95:C6:4F

$ openssl x509 -in 1.intermediate.verisign.cer -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            52:00:e5:aa:25:56:fc:1a:86:ed:96:c9:d4:4b:33:c7
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Validity
            Not Before: Feb  8 00:00:00 2010 GMT
            Not After : Feb  7 23:59:59 2020 GMT
        Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Code Signing 2010 CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:f5:23:4b:5e:a5:d7:8a:bb:32:e9:d4:57:f7:ef:
                    e4:c7:26:7e:ad:19:98:fe:a8:9d:7d:94:f6:36:6b:
                    10:d7:75:81:30:7f:04:68:7f:cb:2b:75:1e:cd:1d:
                    08:8c:df:69:94:a7:37:a3:9c:7b:80:e0:99:e1:ee:
                    37:4d:5f:ce:3b:14:ee:86:d4:d0:f5:27:35:bc:25:
                    0b:38:a7:8c:63:9d:17:a3:08:a5:ab:b0:fb:cd:6a:
                    62:82:4c:d5:21:da:1b:d9:f1:e3:84:3b:8a:2a:4f:
                    85:5b:90:01:4f:c9:a7:76:10:7f:27:03:7c:be:ae:
                    7e:7d:c1:dd:f9:05:bc:1b:48:9c:69:e7:c0:a4:3c:
                    3c:41:00:3e:df:96:e5:c5:e4:94:71:d6:55:01:c7:
                    00:26:4a:40:3c:b5:a1:26:a9:0c:a7:6d:80:8e:90:
                    25:7b:cf:bf:3f:1c:eb:2f:96:fa:e5:87:77:c6:b5:
                    56:b2:7a:3b:54:30:53:1b:df:62:34:ff:1e:d1:f4:
                    5a:93:28:85:e5:4c:17:4e:7e:5b:fd:a4:93:99:7f:
                    df:cd:ef:a4:75:ef:ef:15:f6:47:e7:f8:19:72:d8:
                    2e:34:1a:a6:b4:a7:4c:7e:bd:bb:4f:0c:3d:57:f1:
                    30:d6:a6:36:8e:d6:80:76:d7:19:2e:a5:cd:7e:34:
                    2d:89
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Certificate Policies:
                Policy: 2.16.840.1.113733.1.7.23.3
                  CPS: https://www.verisign.com/cps
                  User Notice:
                    Explicit Text: https://www.verisign.com/rpa

            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            1.3.6.1.5.5.7.1.12:
                0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.verisign.com/pca3-g5.crl

            Authority Information Access:
                OCSP - URI:http://ocsp.verisign.com

            X509v3 Extended Key Usage:
                TLS Web Client Authentication, Code Signing
            X509v3 Subject Alternative Name:
                DirName:/CN=VeriSignMPKI-2-8
            X509v3 Subject Key Identifier:
                CF:99:A9:EA:7B:26:F4:4B:C9:8E:8F:D7:F0:05:26:EF:E3:D2:A7:9D
            X509v3 Authority Key Identifier:
                keyid:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33

    Signature Algorithm: sha1WithRSAEncryption
         56:22:e6:34:a4:c4:61:cb:48:b9:01:ad:56:a8:64:0f:d9:8c:
         91:c4:bb:cc:0c:e5:ad:7a:a0:22:7f:df:47:38:4a:2d:6c:d1:
         7f:71:1a:7c:ec:70:a9:b1:f0:4f:e4:0f:0c:53:fa:15:5e:fe:
         74:98:49:24:85:81:26:1c:91:14:47:b0:4c:63:8c:bb:a1:34:
         d4:c6:45:e8:0d:85:26:73:03:d0:a9:8c:64:6d:dc:71:92:e6:
         45:05:60:15:59:51:39:fc:58:14:6b:fe:d4:a4:ed:79:6b:08:
         0c:41:72:e7:37:22:06:09:be:23:e9:3f:44:9a:1e:e9:61:9d:
         cc:b1:90:5c:fc:3d:d2:8d:ac:42:3d:65:36:d4:b4:3d:40:28:
         8f:9b:10:cf:23:26:cc:4b:20:cb:90:1f:5d:8c:4c:34:ca:3c:
         d8:e5:37:d6:6f:a5:20:bd:34:eb:26:d9:ae:0d:e7:c5:9a:f7:
         a1:b4:21:91:33:6f:86:e8:58:bb:25:7c:74:0e:58:fe:75:1b:
         63:3f:ce:31:7c:9b:8f:1b:96:9e:c5:53:76:84:5b:9c:ad:91:
         fa:ac:ed:93:ba:5d:c8:21:53:c2:82:53:63:af:12:0d:50:87:
         11:1b:3d:54:52:96:8a:2c:9c:3d:92:1a:08:9a:05:2e:c7:93:
         a5:48:91:d3
-----BEGIN CERTIFICATE-----
MIIGCjCCBPKgAwIBAgIQUgDlqiVW/BqG7ZbJ1EszxzANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMTAwMjA4MDAwMDAwWhcNMjAwMjA3MjM1OTU5WjCBtDEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEuMCwGA1UEAxMlVmVy
aVNpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgMjAxMCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPUjS16l14q7MunUV/fv5Mcmfq0ZmP6onX2U9jZr
ENd1gTB/BGh/yyt1Hs0dCIzfaZSnN6Oce4DgmeHuN01fzjsU7obU0PUnNbwlCzin
jGOdF6MIpauw+81qYoJM1SHaG9nx44Q7iipPhVuQAU/Jp3YQfycDfL6ufn3B3fkF
vBtInGnnwKQ8PEEAPt+W5cXklHHWVQHHACZKQDy1oSapDKdtgI6QJXvPvz8c6y+W
+uWHd8a1VrJ6O1QwUxvfYjT/HtH0WpMoheVMF05+W/2kk5l/383vpHXv7xX2R+f4
GXLYLjQaprSnTH69u08MPVfxMNamNo7WgHbXGS6lzX40LYkCAwEAAaOCAf4wggH6
MBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXAzBW
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwDgYDVR0PAQH/
BAQDAgEGMG0GCCsGAQUFBwEMBGEwX6FdoFswWTBXMFUWCWltYWdlL2dpZjAhMB8w
BwYFKw4DAhoEFI/l0xqGrI2Oa8PPgGrUSBgsexkuMCUWI2h0dHA6Ly9sb2dvLnZl
cmlzaWduLmNvbS92c2xvZ28uZ2lmMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTMtZzUuY3JsMDQGCCsGAQUFBwEBBCgwJjAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDAzAoBgNVHREEITAfpB0wGzEZMBcGA1UEAxMQVmVyaVNp
Z25NUEtJLTItODAdBgNVHQ4EFgQUz5mp6nsm9EvJjo/X8AUm7+PSp50wHwYDVR0j
BBgwFoAUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwDQYJKoZIhvcNAQEFBQADggEBAFYi
5jSkxGHLSLkBrVaoZA/ZjJHEu8wM5a16oCJ/30c4Si1s0X9xGnzscKmx8E/kDwxT
+hVe/nSYSSSFgSYckRRHsExjjLuhNNTGRegNhSZzA9CpjGRt3HGS5kUFYBVZUTn8
WBRr/tSk7XlrCAxBcuc3IgYJviPpP0SaHulhncyxkFz8PdKNrEI9ZTbUtD1AKI+b
EM8jJsxLIMuQH12MTDTKPNjlN9ZvpSC9NOsm2a4N58Wa96G0IZEzb4boWLslfHQO
WP51G2M/zjF8m48blp7FU3aEW5ytkfqs7ZO6XcghU8KCU2OvEg1QhxEbPVRSloos
nD2SGgiaBS7Hk6VIkdM=
-----END CERTIFICATE-----

2.root.verisign.cer

$ openssl x509 -in 2.root.verisign.cer -noout -fingerprint
SHA1 Fingerprint=4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5

$ openssl x509 -in 2.root.verisign.cer -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            18:da:d1:9e:26:7d:e8:bb:4a:21:58:cd:cc:6b:3b:4a
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Validity
            Not Before: Nov  8 00:00:00 2006 GMT
            Not After : Jul 16 23:59:59 2036 GMT
        Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:af:24:08:08:29:7a:35:9e:60:0c:aa:e7:4b:3b:
                    4e:dc:7c:bc:3c:45:1c:bb:2b:e0:fe:29:02:f9:57:
                    08:a3:64:85:15:27:f5:f1:ad:c8:31:89:5d:22:e8:
                    2a:aa:a6:42:b3:8f:f8:b9:55:b7:b1:b7:4b:b3:fe:
                    8f:7e:07:57:ec:ef:43:db:66:62:15:61:cf:60:0d:
                    a4:d8:de:f8:e0:c3:62:08:3d:54:13:eb:49:ca:59:
                    54:85:26:e5:2b:8f:1b:9f:eb:f5:a1:91:c2:33:49:
                    d8:43:63:6a:52:4b:d2:8f:e8:70:51:4d:d1:89:69:
                    7b:c7:70:f6:b3:dc:12:74:db:7b:5d:4b:56:d3:96:
                    bf:15:77:a1:b0:f4:a2:25:f2:af:1c:92:67:18:e5:
                    f4:06:04:ef:90:b9:e4:00:e4:dd:3a:b5:19:ff:02:
                    ba:f4:3c:ee:e0:8b:eb:37:8b:ec:f4:d7:ac:f2:f6:
                    f0:3d:af:dd:75:91:33:19:1d:1c:40:cb:74:24:19:
                    21:93:d9:14:fe:ac:2a:52:c7:8f:d5:04:49:e4:8d:
                    63:47:88:3c:69:83:cb:fe:47:bd:2b:7e:4f:c5:95:
                    ae:0e:9d:d4:d1:43:c0:67:73:e3:14:08:7e:e5:3f:
                    9f:73:b8:33:0a:cf:5d:3f:34:87:96:8a:ee:53:e8:
                    25:15
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            1.3.6.1.5.5.7.1.12:
                0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
            X509v3 Subject Key Identifier:
                7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33
    Signature Algorithm: sha1WithRSAEncryption
         93:24:4a:30:5f:62:cf:d8:1a:98:2f:3d:ea:dc:99:2d:bd:77:
         f6:a5:79:22:38:ec:c4:a7:a0:78:12:ad:62:0e:45:70:64:c5:
         e7:97:66:2d:98:09:7e:5f:af:d6:cc:28:65:f2:01:aa:08:1a:
         47:de:f9:f9:7c:92:5a:08:69:20:0d:d9:3e:6d:6e:3c:0d:6e:
         d8:e6:06:91:40:18:b9:f8:c1:ed:df:db:41:aa:e0:96:20:c9:
         cd:64:15:38:81:c9:94:ee:a2:84:29:0b:13:6f:8e:db:0c:dd:
         25:02:db:a4:8b:19:44:d2:41:7a:05:69:4a:58:4f:60:ca:7e:
         82:6a:0b:02:aa:25:17:39:b5:db:7f:e7:84:65:2a:95:8a:bd:
         86:de:5e:81:16:83:2d:10:cc:de:fd:a8:82:2a:6d:28:1f:0d:
         0b:c4:e5:e7:1a:26:19:e1:f4:11:6f:10:b5:95:fc:e7:42:05:
         32:db:ce:9d:51:5e:28:b6:9e:85:d3:5b:ef:a5:7d:45:40:72:
         8e:b7:0e:6b:0e:06:fb:33:35:48:71:b8:9d:27:8b:c4:65:5f:
         0d:86:76:9c:44:7a:f6:95:5c:f6:5d:32:08:33:a4:54:b6:18:
         3f:68:5c:f2:42:4a:85:38:54:83:5f:d1:e8:2c:f2:ac:11:d6:
         a8:ed:63:6a
-----BEGIN CERTIFICATE-----
MIIE0zCCA7ugAwIBAgIQGNrRniZ96LtKIVjNzGs7SjANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMDYxMTA4MDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2ln
biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJp
U2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y
aXR5IC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1
nmAMqudLO07cfLw8RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbex
t0uz/o9+B1fs70PbZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIz
SdhDY2pSS9KP6HBRTdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQG
BO+QueQA5N06tRn/Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+
rCpSx4/VBEnkjWNHiDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/
NIeWiu5T6CUVAgMBAAGjgbIwga8wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E
BAMCAQYwbQYIKwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAH
BgUrDgMCGgQUj+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVy
aXNpZ24uY29tL3ZzbG9nby5naWYwHQYDVR0OBBYEFH/TZafC3ey78DAJ80M5+gKv
MzEzMA0GCSqGSIb3DQEBBQUAA4IBAQCTJEowX2LP2BqYLz3q3JktvXf2pXkiOOzE
p6B4Eq1iDkVwZMXnl2YtmAl+X6/WzChl8gGqCBpH3vn5fJJaCGkgDdk+bW48DW7Y
5gaRQBi5+MHt39tBquCWIMnNZBU4gcmU7qKEKQsTb47bDN0lAtukixlE0kF6BWlK
WE9gyn6CagsCqiUXObXbf+eEZSqVir2G3l6BFoMtEMze/aiCKm0oHw0LxOXnGiYZ
4fQRbxC1lfznQgUy286dUV4otp6F01vvpX1FQHKOtw5rDgb7MzVIcbidJ4vEZV8N
hnacRHr2lVz2XTIIM6RUthg/aFzyQkqFOFSDX9HoLPKsEdao7WNq
-----END CERTIFICATE-----


Well in answer to your question as to whether there's a better way to do this, I'm wondering if a slightly simpler solution which I've used previously might be up to the task.

Rather than generating a pre-defined list of challenges and transmitting them, have the client and server each add a predictable incremental value to the hash you pass in the header. Both the client and the server keep count of the number calls/responses for the session and can reject any received with duplicate (re-used) hashes. The incremental value can be as simple as a count, or could be some simple maths function performed on the count if you're feeling particularly paranoid.

It would look something like this:

Client wants to log in and sends a login request with userid &
hash(some sensible combination of shared secret with userid or some
such).
Server examines the hash and if correct, returns success and a
session token.

Now for each call made:

Client calls API endpoint X on server, with added header hash(session-token, incremental value)
Server verifies the hash matches the session-token & the next incremental value expected for this session, if it does it sends the response from the endpoint also signed with hash(session-token, next incremental value).
The client verifies the response header contains a hash of the session token and the next incremental value it was expecting.

and repeat.

If any request/response arrives with a re-used hash in the header, the incremental value will be out of sequence and the client/server can reject it. Also there's no need to worry about generating, transmitting and maintaining a list of challenges for the session.

Downsides here involve problems caused making multiple calls and them getting out of sequence either due to network issues or the design / requirements of the application. Ways around this involve adding a central point to the client to marshal/queue all requests and responses for the session, or alternatively create a separate session for each thread or conversation within the client application. That's extra consideration during development maybe, but if your requirement to keep traffic to a minimum is important enough it might be worth the effort.

Comments and thoughts are very welcome.


Is there any mechanism to audit which signed certificates are unrevoked?

Certificates are for authentication, not for authorization.

Authentication is (here) about the OpenVPN server making sure that the alleged client is who they claim to be. This is the point of certificates: the client shows his certificate, which contains his public key and identity; the server validates the certificate (with regards to its trusted CA) to make sure that the certificate contents are genuine; the client demonstrates mastery of the corresponding private key (normally by generating a signature based on a challenge from the server -- this is done within the particulars of the communication protocol). That way, the server learns that whoever is at the other end of the line really is the owner of the public key which is in the client certificate; and the certificate, being verified to be genuine, allows the server to infer that the identity in the certificate really is that of the key owner.

Authorization occurs as a second step. Now that the server knows who is calling, it must still decide whether that client shall be granted access or not. This is a server-side decision.

From your description, you (apparently) configured OpenVPN to use certificates for authorization; or, said otherwise, you apply "automatic authorization" which grants access to anybody who could get authenticated. This is the root of your problem; certificates are not good for authorization. As you noticed, if you use such an authorization rule, then the "allowed users" cannot be reliably listed, unless you keep knowledge of all issued certificates. Also, if you want to close the access for a user, then you normally need to close it now, not within one week; but revocation is asynchronous and will be really effective only when the previous CRL has expired.

While a good CA must retain precise knowledge of all the certificates it has issued (if only to be able to revoke a certificate at will), there is no mechanism in X.509 to ensure the consistency and integrity of such a list. Moreover, the asynchronous nature of revocation is further proof that certificates provide inadequate means of authorization.

What you really need is to maintain an exhaustive list of "allowed users" on the server side (in the OpenVPN configuration files). The users would be identified by their name (apparently, OpenVPN uses the 'Common Name' part of the subjectDN in certificates to reference users); the server will extract the client identity from the incoming client certificates and authorize the user only if it appears in the list of allowed users. If you deploy such explicit authorization, then you have your reliable list of allowed user since, by definition, it is the list that the OpenVPN server uses to grant or deny access. Moreover, it allows you to block and unblock access for any specific user instantly.


How do I know that the ISO image of the Linux distribution I have downloaded does not contain the NSA backdoor?

You've specified that you don't care about source code vulnerabilities, so then the question really is "How do I verify that I've installed a legitimate binary?".
This depends on your distribution.  Most of them have some level of cryptographic signing of packages; for instance, there will be a package that installs the GPG keys for the distro packagers, and every downloaded package is checked against your keychain.


How helpful is encrypting/decrypting information on an app-server, and sending it to the database encrypted?

Since there's not been an answer, I'll take a shot at this... but there are other questions about Database Encryption already, so you might want to check some of them out, as well.

As for how Database Dumps are acquired:

Backups
SQL Injection
Open Ports and the related terror of Default Passwords
Production Snapshots used in Development or Staging

While it's possible that an attacker could just acquire the encryption key from disk as you suggest... I cover some ways to mitigate that risk in a previous answer.

As for it's overall effectiveness... I wish I had some statistical resource to call on, but I don't. Intuitively, it would seem to protect your data with most static dump approaches. It increases the complexity requirement for an attacker - which is generally exactly what you want - since they will now need to breach your application layer to get the keys, in addition to the database layer.

The Patreon Breach is generally my favourite example of how Database Encryption helps to mitigate the fallout of a major incident.


For starters, the HTML input tag in this case is set to restrict input to 15 characters, so your standard <script>alert(1);</script> won't fit.  This can probably be circumvented by using an attack proxy such as OWASP ZAP or Burbsuite, which will allow you to submit responses that wouldn't normally be accepted.

There is no way to tell what server-side filters are in place by simply looking at the HTML code.  HTML is client-side, and client-side security can almost always be bypassed.  (Much like the character limit described above.)  It is likely that there are multiple layers of filtering that go on in the server after you submit the form.

There are two steps that you should try.  First, rather than starting off with a whole payload script, try just entering specific characters and combinations of characters, such as < and >.  See what characters get filtered out, and which ones become encoded or remain unfiltered.  Then try to craft an attack string that will bypass the filtering or is the decoded form of what you actually want.

The other thing you should do is to run a fuzzer on the application.  This will try a very large number of different attack strings, to try to find one that gets by the filtering.


Assuming that this is a homework question, the key here is how difficult it is for the attacker to get confirmation that they have guessed correctly.  For a given number of options that an attacker has to guess and will be given confirmation of being correct, it takes half the total number of possibilities on average to get a hit.

If you have 5000 possible passwords, then it will take an average of 2500 guesses to find it (via brute force).  If the three passwords must all be entered before confirmation is given about any of them being correct, you would need to figure out the number of possible guesses for all three passwords.  If each password is confirmed separately however, you only need to know the number of guesses to get each password and to guess them 3 times.

This is of course assuming that there are no other, more subtle weaknesses in the system.  For example, if the system stored hashes of the passwords that might be compromised, then it wouldn't matter if confirmation was given between the passwords or not since the hashes for each would allow the attacker to verify it for themselves.


How do I sign another person's key and make the signature expire?

[Edit after the clarification]:

I believe you are looking for the "esoteric options of the GPG", you can have a look at them in here:

http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Esoteric-Options.html

Specifically you are looking for the option:

--ask-cert-expire

Use it when issuing a new key.


DNS Rebinding attack - will the victim's browser send cookies?

"The attacker registers a domain (such as attacker.com) and delegates it to a DNS server he controls. The server is configured to respond with a very short time to live (TTL) record, preventing the response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the malicious client-side code.

The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the same-origin policy. However, when the victim's browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. For instance, he could reply with an internal IP address or the IP address of a target somewhere else on the Internet."

Simplifying:

Victim enter in evil.com
evil.com responds with X.X.X.X (IP of malicious server)
X.X.X.X loads a malicious script
Malicious scripts makes requests to evil.com (same domain)
But now evil.com responds with 201.82.108.103 (IP of Google)

Attack done!
The malicious script can now makes requests to Google (pseudo Cross-Site Scripting), because theoretically it is not violating same-origin policy. It is accessing Google, but using evil.com as domain, and it was loaded under evil.com, so the browser can not see any problem with the requests.


When TrueCrypt prompts to re-enable automatic mounting, should I be worried?

I did some digging and it turns out if this is your main hard disk (containing the partition of the OS), it is highly unlikely that removal and reattachment to your laptop would leave anything but a physical trace.

Unless you keep track of the HDD S.M.A.R.T counters for how many times the device has been powered up (Which we normally don't keep track of), before and after your suspected problem its difficult to say if the drive was removed and accessed offline.

And paranoia is always relative to risk. In some cases you DO need to be paranoid. But as long as you are using a decently strong Encryption Key and do the best to make sure that no one else has access to that key, you should be fine as brute-forcing a strong key would in any case take a considerable amount of time.


It is save to send sensitive data through URL parameters inside one service with SSL?

When you are connected with HTTPS to a website, only the domain will be visible to others when they lets say use Wireshark, not the URL parameters. However, there are more risks involved.

There is no significant difference to POST and GET requests when it comes down to altering the values for example, any user can easily edit a POST request just as easily as altering the URL. You can also see POST packages being send over the network when not using HTTPS to connect.

However, GET requests can be cached and will remain in the browser history. They can also be bookmarked and these are main risks involved. Best practice is to not use GET requests for sensitive data.


Environment variables vs secrets managers

Store secrets on environmental variables is a bad idea, if you don't have more options of course you can go for it, but having your secrets on a specific service for store this type of information gives you more benefits in terms of security and management.
For example your JWT stored encrypted on your service will directly go safely from the disk of the service (that is properly encrypted), directly to your service with TLS or mTLS to the memory of your backed. Also if you server is compromise your secrets wont be compromised. I'm sure there are more benefits but those are the ones that came to my mind easly


Is autocorrecting typos in passwords secure?

Full disclosure: I am one of the authors of the paper.

An exact password checking system stores a standard salted,
slow-to-compute hash of the password. When a password, such as
password123, is registered with the authentication service, a random salt
"sa" is selected (this should be 16 or more random bytes) and a
slow-to-compute hash function H is applied: H(sa,password123). The result,
call it h, is stored in a database along with the salt sa. As mentioned,
one should pick H to be slow (10s or 100s of milliseconds to compute).
Good choices are argon2, scrypt, or PBKDF2, properly configured.

When a user later attempts login, if they type in their password the hash
is recomputed and checked against the stored value. In the example above,
if the user sends password123 then one recomputes (again slowly)
H(sa,password123) and checks the result --- it matches the previously
computed h and login can be allowed.
Any deviation in the submitted password from the previously registered one
results in a totally different hash value, and login fails.

Our idea is simple: if the first check fails, the system can additionally
apply a small number of "corrector" functions to the submitted password,
and then apply the hashing algorithm to the result. For example we might
fix a caps lock corrector function F_caps that takes as input a password
and outputs the password with the capitalization of all letters changed:
F_caps(PASSWORD123) = password123 and F_caps(pAsSwOrD123) = PaSsWoRd123.
We might also fix a first-letter capitalization corrector:
F_first(Password123) = password123 and F_first(pASSWORD123) = PASSWORD123.
Note that these are simple to implement.

Then to do typo-tolerant checking one would apply the following logic for
a previously registered salt, hash pair (sa,h) and submitted password pw

If H(sa,pw) = h or H(sa,F_caps(pw)) = h or H(sa,F_first(pw)) = h then
allow login

As an example, if one submitted PASSWORD123, the checks would be on
PASSWORD123, password123, and pASSWORD123, with the second check
succeeding.

A few points:

1) The efficacy of offline brute force attacks are exactly the same as
before. Why? Because we only store sa,h. The attacker, given sa,h, will
only learn the password via a brute-force attack that tries the correct
password, in our example password123. There is no loss in security here as
we haven't changed how H is computed.

2) There is negligible change in the security against remote guessing
attacks. We show this via extensive analyses in the paper, but it boils
down to the fact that in the real world the best strategy is to submit the
most likely passwords up to some threshold (e.g., many sites lock an
account after 10 failed attempts). The extra checks performed due to typo
correction may help the attacker get a little bit more lucky, but we show
that it is essentially negligible. If one is worried about it we give
techniques that reduce it even further.

3) Typo-tolerance will increase CPU utilization for the login server (and
possibly memory load, when H is a memory-hard hash such as scrypt or
argon2). This is because of the extra slow-to-compute invocations of H. In
practice this doesn't seem to be as much overhead as you might expect (3x
in our example above) because anyway users would have ended up
resubmitting after rejection and you pay the price for each attempt.

4) We do not suggest allowing arbitrary typos. This isn't even possible
currently, as it would require recomputing H a prohibitive number of times
(remember it is slow!), and anyway this would be insecure. One needs to
carefully choose which typos to allow based on a principled analysis. We
believe the two correctors mentioned above, caps lock and first letter
capitalization, are a no-brainer for secure deployment, beyond that it
starts getting more nuanced.

We added an FAQ that provides additional information:
https://www.cs.cornell.edu/~rahul/projects/pwtypos.html


Thinking in "layers" can be confusing. Layers come from the OSI model which was meant for another set of protocols, former competitors of what became TCP/IP (the "Internet protocol" that we use nowadays). If you want to put SSL into the layers model, your more-or-less have to put it on layer 6 or more, but also below layer 4 at the same time, which does not work. The "layer model" cannot really digest SSL.

When you want security, when talking to "a server", you want several things:

Confidentiality: people who can spy on wires must not be able to understand the data you exchange.
Integrity: people who can plug on wires must not be able to alter the data while it transits.
Authenticity: when you talk to a server, you must have some reasonable guarantee that you are talking to the genuine server, not to some attacker-controlled faked.

SSL is "end-to-end": it ensures these characteristics regardless of how the data bytes are physically transported. Encryption systems applied on "lower layers", usually, lack this wide scope. E.g., when using a WiFi access point, there is some encryption which occurs between your laptop and the access point, but it stops there. The access point itself, and routers beyond that access point, will see the cleartext data.

There are end-to-end protocols which purport to integrate with TCP/IP at a lower level (e.g. IPsec), but they don't get used as widely as SSL for "usual browsing" because of historical tradition. Indeed, if you want some security between your Web browser and a Web server, then both the browser and the server must support the same relevant protocol and agree to use it; right now, the only protocol which "works everywhere" is SSL (which is why people concentrate on SSL support, which is why SSL works everywhere, which is why people concentrate on SSL support, which...).


Generating QR-Code for 2fa from google maps api risky?

I would not be that paranoid but yes, why should somebody know you have generated some access tokens for whatever purposes...

Why you can't use your own generator? It is not something secret. There are tons of implementations on the internet for various languages...

Here is javascript implemenation:

Example:
https://stefansundin.github.io/2fa-qr/

Sources:
https://github.com/stefansundin/2fa-qr/blob/gh-pages/index.html

Here is one in PHP:
https://github.com/chuyskywalker/google-authenticator-qrcode


Replay Safe Mutual Authentication (libsodium)

Does Bob need to record every nonce (...)?

No.

You're right that a nonce must not be used twice. However, bookkeeping nonces is not the way to go. The usual approach is to include a timestamp in its value and/or to generate random nonces with enough random bits. This doesn't garantuee double use but makes it highly unlikely.

May I recommend crypto.SE for questions regarding the implementation of cryptographic protocols?


How to harden Adobe Acrobat and Acrobat Reader

Disabling JS is actually a very good idea. If you still want to add some extra protection I would recommend:

Set the security options to the highest level. Acrobat Reader implements a sandbox mode, which is called Protected mode and is usually enabled by default. You can also enhance it using the Protected View:

https://helpx.adobe.com/reader/11/using/protected-mode-windows.html

Use an up-to-date version of Acrobat Reader to avoid n-days and vulnerabilities which could undermine the security of the product


paj28's solution works. I had to go to IcedTea's configuration and add the Burp certificate to the list of certificates and then configure IcedTEa to use Burp as a proxy. I don't now why but IcedTea seemed to mess up (refusing to launch the applet) at first, but after a few attempts it works!


Tunnel between two applications, one of them is a 3rd party app

It sounds (from the comments) like you're just launching another process and not interacting with it after that, right? In that case, there isn't any direct communication between the processes at all! Instead, your process tells the OS "hey, I want to create a process, here are the details including args", and then the OS creates a process including setting up its initial variables (environment variables and command-line arguments). The OS will also return some details to your process (notably the PID of the new process and a HANDLE to it, which a framework such as .NET wraps for you) but that's sent back by the OS, not by the other process.
Talking about a "tunnel" doesn't make any sense in this scenario, because at the time of the "communication", the "recipient" doesn't even exist yet! For it to make sense, you'd have to launch the new process in a way where it can communicate with your process once the new one is running. Sometimes this is an option - some programs can take data from stdin in place of command line args, or can read their arguments out of a file (which might theoretically be a pipe, although many won't like that). However, that depends on how the program is written, and you said you don't control that.
I assume your goal is protect the command line arguments from being captured by an attacker. I have good news and bad news.
The bad news is that command line args are generally not secret. You can see them in Task Manager, for example, if you enable the relevant column in Details view. Processes owned by other users won't have readable command line args unless you're an Administrator, but anything running as you-the-user will have access if it wants. Of course, it doesn't even matter whether the args are directly exposed; any process running with the same privileges as any other process (or running as admin) can simply read the other process' address space directly, pulling any desired secrets right out of memory (the relevant APIs are usually used for debuggers).
The good news is that, assuming you don't have malicious software running on your machine (or at least not with sufficient privileges), the command line args aren't exposed to interception anywhere. They might get stored in a Windows system log (depending on logging settings) but they aren't transmitted over the network or anything like that. The creator process invokes a system call or two (NTCreateProcess on Windows, something like fork or clone followed by execve on *nix systems) which passes the parameters directly to the kernel. It is in theory possible to intercept this, but if your attacker can interfere with system calls you have Much Bigger Problems, as that means they have already taken over either your process or your entire kernel! The kernel then creates the new process and sets its memory such that it sees the arguments you passed it; this is only interceptable if the entire machine is already compromised.
Now, of course, what the new process does with those arguments is entirely up to it! You seem to be starting something that wants a remote host and credentials to access it, which suggests that the credentials will be sent over the network. That's the part you should be worried about, unless you expect your user (the person running your software) to be malicious or to have malicious code running with their privileges... in which case there's nothing to be done, game over.


How to find out whether an ISP adds a perma-cookie to my requests?

Send a request to a server you control and see it it was altered in transit; you may also use a online service like HTTPBin, it's designed to test HTTP client libraries and has pages that return the exact request content, so you'll see if additional cookies were added.

Note that ISPs can be sneaky about this and only add the cookies in requests to their partner's websites, in this case I don't see an easy way to detect this without getting access to their partner's servers, but a reliable way of mitigating this would be to use HTTPS which prevents MITM attacks like the one you describe.

For HTTP sites you'll need to pass your traffic through an encrypted (IPSec ?) tunnel to a server behind a reliable and respectful ISP.


Can a service be Oauth2 provider and Oauth2 client at the same time?

Yes, this is very common and one of the scenarios facilitated by identity protocols like OAuth2 and SAML.

Let's say you have an application and you decide to outsource identity management, e.g. to Azure AD B2C.

Your application will be an OAuth2 or OpenID Connect client to Azure AD B2C.

Now you want your users to be able to use an email/password combination or login using identity providers (IDPs) like Facebook or Google (the kind of experience login.realmadrid.com has, which uses AAD B2C).

So the user comes to your application and clicks "sign in". Your application will send the request to AAD B2C, which will ask the user to enter email/password and show buttons for Facebook and Google. If the user now clicks one of those buttons, then AAD B2C becomes a client and sends the user to either of those IDPs using OAuth2.

User enters credentials in Facebook or Google, they issue token to AAD B2C, which it will consume and then issue a token to your app.

Now your app doesn't really need to change as additional IDPs are added or existing ones removed, or if IDPs use different protocols because your app only needs to interact with AAD B2C.


(How) Can outsiders discover the pages that are being hosted on my server?

Your "secret files" remain secret exactly as long as their names (with full path) remain secret. You may consider the path as a kind of password. Note that the paths will leak to various places (proxy, Web server logs, history of your browser...). If the files are important and sensitive, you should just do things properly:

Use SSL for upload and access to these files.
Setup an access password for the directory where the files are.

That way, you are back to known waters: you have a (part of) Web site with sensitive data and protected by a password. Make it strong, and you are all set.

In the case of the sub-domain: that "sub-domain" is advertised to the World at large through the DNS. It is possible to configure DNS servers so that outsiders cannot easily enumerate all sub-domains of a domain, but this takes some care. Moreover, whenever you access that sub-domain, your machine will use DNS queries (for the corresponding IP address); these queries travel without any particular protection, and contain the sub-domain name. Thus, this is an easy prey to passive eavesdropper (i.e. "people connected to the same WiFi access point as you"). It would be overly optimistic to believe in the secrecy of a sub-domain.


In a LAN environment, can you fake the IP address while also being able to receive the response?

A network switch works by inspecting packets as they come and go. When a switch sees that a packet arrives on a given port, bearing the source MAC address X, then the switch remembers that the machine with MAC address X lies at some point beyond that port, and packets destined to the MAC address X will be sent to that port. Note that switches don't care about IP addresses (well, some switches double as traffic inspectors and know what IP addresses are, but the switch behaviour occurs at the ethernet level and deals with MAC addresses, not IP addresses).

If the attacker is sending packets with X as source address, and expects responses which are destined to address X, then, by any reasonable definition, X is not a "fake address": it is the address that the attacker is assuming, and, from a network point of view, it is very real.

The real trouble comes when the attacker tries to steal an IP address. The attacker observes that there is an active machine, with some IP address U and MAC address Y, and the attacker wants to emit packets which will look as if they come from that machine, and also see the response from another machine V. The attacker has two possible ways:

The attacker may try to use an address X distinct from Y, but yet steal address U. The trouble is that the machine V is aware that the genuine machine U has MAC address Y; this awareness comes from the ARP protocol. To achieve his goals, the attacker will have to spam machine V with fake ARP responses so that V becomes convinced that the MAC address for address U is X. This is known as ARP spoofing or "ARP poisoning".

Note that the switch sees only MAC addresses Y and X, duly distinct from each other, and has no impact here. The attacker has nothing special to do to fool the switch if he chooses this way.
The attacker may try to use both the IP address U and the MAC address X. The good point of this method is that there is nothing to do with regards to machine V: that machine remembers that U maps to X, and, as far as the attacker is concerned, this is fine. On the other hand, the switch becomes a problem: that switch has already seen some packets with source address X, coming from a port other than the one used by the attacker. The attacker may not see the response.

To counter that, the attacker will first spam the switch with thousands of packets, full of random junk, allegedly coming from thousands of random MAC addresses. The switch has only limited RAM to remember all the mappings of MAC addresses to ports, so the spamming onslaught will make it forget where address X is. At that point, given a packet with destination address X, the switch will degrade to hub mode and broadcast the packet on all ports -- including the one leading to the attacker.

The situation can be made more complex with modern switches which employ more complex routing algorithms to support redundant networks. The base principle is still that the MAC addresses are unknown to the switches, who discover them dynamically by observing packets in transit. A countermeasure which can be employed with some switches is ton configure them, statically, with known associations of MAC addresses with ports. This loses in flexibility (a specific machine will be rejected if not plugged on the right port), but can make switches more robust against such attacks.

(Not letting evil people connect directly to your switch would be better, though.)


Prevent credential roaming for certain accounts/certificates?

I have never actually done this. But here's a few things Google brought up:

  Is there any way to prevent certain certificates from roaming?

MS says to link them to a different account altogether, or put them on a smart card.

  Or if not, disable it for certain users?

Because CR works with a user GPO, you could deny some users "apply group policy" permissions to that GPO.


Veracrypt - When using Full OS encryption, isn't it easier to decrypt using the OS file placement?

In a properly implemented encryption scheme, comparing the encrypted and unencrypted data does not provide any clues about the password used to encrypt, as you seem to think.

Any high quality Symmetric Encryption algorithm will include an Avalanche Effect so that if even a single bit of the key is wrong, then the entire result will appear random, and therefore not provide any clues. The attacker does not know whether a guessed key is slightly wrong, or completely wrong.

Also note that the Encryption/Decryption Key is actually Derived from the user's Password using a Key Derivation function. The purpose of using a Key Derivation function is to create a fixed-length key (i.e. 128 bit key for an AES-128 encryption) based on a variable length password (i.e. most passwords are less than 128 bits), including its own avalanche effect. Also the Key Derivation function is usually somewhat processor intensive to reduce the amount of Entropy required for a password to be safe from brute force.

(In your example, it seems you have a XOR cipher, which does not include an avalanche effect.)


Is it possible to configure any of wifi protocols so that the network is undetectable?

No, the spectrum that is used is well-known and not concealed.  You can't conceal that activity is occurring, you can only prevent the SSID from being directly broadcast and encrypt the traffic such that the network can not be spied on without breaking the encryption.  The fact that there is radio activity in the spectrum will be apparent to anyone listening in and the encrypted messages will be able to be captured without trouble.

In order for a radio to be able to send a signal, it has to appear above the noise.  The only exception to this is when using specialized jamming equipment that allows signals to be sent through it (which is also not WiFi) (generally by not blocking frequencies in a pattern derived from a key), but even then, it is obvious that there is a transmitter there.

You are correct that a good encryption algorithm and key should make the cipher-text look random, but there has to be some kind of way for signal to stand out from random noise.  Say that you have a signal that looks random 10011011 and then have actual random noise 01011010.  When you combine them, you 11022021, but now since the noise was truly random, how do you know what was noise and what was signal?  You can't because you don't have a pattern to the noise.

If you generated the noise, then you could have a pattern and drown out the natural noise, but then we are back to the situation I described for signal jammers, you are going to know they are there because it needs to be enough louder than passive noise to be distinguished from background noise.  Such a system would also have to drown out any other signals in the spectrum in the area as they would also be effectively random interference which would make such a device illegal to operate for most purposes in the US due to FCC requirements that a device not cause interference.


Preventing tracking pixels on Mozilla Thunderbird

Thunderbird on Linux, I assume Windows is similar, has 3 viewing settings:

View

Message Body As

Original HTML
Simple HTML
Plain Text

Original will pull from remote locations to include trackers.

Simple will display only embedded content such as attachments or inline pictures.

Plain is text only with no HTML processing at all.

Setting to "Simple" will eliminate tracker loading as well as all remote loads.


Best practices for sending tax data to and from a tax professional

In this case, using some form of encryption is the best.  However, the problem with encryption when talking to non-technology professionals is usually two fold:

Exchanging the password is often done insecurely, e.g. "send a password in a separate e-mail."  Password exchange, if using password protection, should be done on the phone or offline.  Also, as you've noted, often passwords are easy to guess.
Difficulty to use:  Often the user experience of using encryption tools (such as PGP) is so prohibitive, either for the person sending it or the recipient, that security measures are turned off or weakened in order to make it easier.

PDF encryption when using modern PDF software is actually pretty good and uses AES by default, at least in Adobe's implementation.  However, if you use a weak password, then those benefits are largely undone.

However, there are some good solutions out there that are easy to use:

E-mail encryption plugins:  There are various easy-to-use software out there for securing e-mails.  An example of this is Virtru.
Self-hosted File sharing services like ownCloud:  You can setup an instance of ownCloud to securely share files with a link and expiration dates can be set for files.
Hosted file sharing services like box.com:  You can share files encrypted with passwords and expiration dates.

I'd recommend suggesting these options to your tax preparation company, so they can avoid potentially costly and burdensome security incidents due to their current practices.


Utility company does not hash passwords in the database

There are two sides to this problem:

Security implications for you

Basically, the only working mitigation is to use a different password on every account you own (And then, use a password manager like KeePass, 1Password, etc. to store them)

For the utility company

Hashing passwords adds security. Unfortunately, it also adds cost - to implement it, to test, etc. Password recovery procedure will change, etc, etc, etc.

Basically, you need to be a good salesman to explain their risks to them and show them that the potential losses (reputation, etc) are worse than the cost of hashing - if it really is.

So, to do that, you need to get in contact both the CISO (or CIO, or CTO), and then, after convincing him :) - approach those who will shell out the money for this.


How were nuclear launch codes authenticated?

The details have of course changed with time and technology. For many years the final launch code deep inside the ICBM missle sites was "00000000" 20 years Launch Code. The logic was that it was a very difficult assignment for constantly rotating crew in the bunkers and they needed something they could remember.

It has been standard policy in the U.S. to always maintain a human in the loop, multiple humans actually, to preclude any possibility of an automated launch.

There are a number of relatively current descriptions of the details:

Bloomberg

Old Nike Launch

Wikipedia Gold Codes


SAML Assertion to Windows Identity (Kerberos token?) transformation

The issue is that you're needing to translate a SAML identity to an identity provided by Active Directory, and Active Directory doesn't understand SAML. That's where the C2WTS service came into play. It's not deprecated, but is frowned upon using because it allows impersonation of any user assuming you've given the service account enough rights to do so, and those rights basically give you root equivalent.

You can either use that service, which is probably the preferred option, or you can build your own mechanism that calls into the Windows subsystem for impersonating users. Something along the lines of this: https://stackoverflow.com/questions/559719/windows-impersonation-from-c-sharp.


Ability To Change Root User Password (Vulnerability?)

You pretty much hit the nail on the head when you said that you need physical access to the machine.

If you have physical access, you don't need to go through the official steps to reset the root password, as you can flips bits on the hard drive directly, if you know what you're doing.  I.e., you can boot up a recovery OS from a DVD or flash drive, and mount the drive that way to gain complete read/write access to the entire disk.

Disk encryption will mitigate the risk, but doesn't remove it entirely* but makes attacks much more complicated.  It is best to assume that an attacker with physical access will be able to influence every aspect of the device in time.

Since it's assumed that attackers with physical access will always gain privileged account access eventually, there's little point in putting the legitimate administrators through extra trouble if they lost their password.

Every Linux distro that I have used has had this feature, though it's possible that some of the distros aimed at a more paranoid audience could disable this.

In addition, it's a standard feature in BSD Unixes, was tested for on the CCNA exam at least 15 years ago when I took it for Cisco devices, and it's fairly trivial to reset passwords on a Windows machine if it isn't explicitly secured.

* The attacker could for example add a backdoored kernel or initrd in the /boot directory, that needs to be unencrypted because the bootloader must be able to read the kernel and initrd files.


Why can't I transfer executable files with netcat?

The "doubling in size" to me smells like Unicode encoding at work. Does your Windows netcat have any option for binary only transfer?
To verify, does the text on Linux remain readable and apparently identical, but become _t_e_x_t (_ representing a 00 hex) if you look at it with a binary editor, on Windows?
From your comments, "a simple text file I can transfer the file from Kali onto Windows no problem" and "In fact it seems that even the text files double in size once transferred", it looks as if the text remains readable and apparently identical if you open it on Windows, and yet its size changes. In my experience, if it changes by very little (one character every row) that's linefeed encoding, if it doubles straight then it's two-byte encoding on Windows.


Is it possible to ensure detection and logging of all attempts to copy data out of a system?

It's possible to monitor access to select data. It's possible to monitor selected tool use like scp.
I've lost track of how many times I've seen claims of security because all data is kept in the cloud or something similar. What is often forgotten is the underlying detail of function. If a user is reading/viewing the data, it's on his device! It can be made inconvenient to extract it but photographing the screen always works.
If the data is never viewed, just processed, then you can attempt to detect exfiltration of the raw data. Common mechanisms include:

Forcing all access through a decrypting MiTM type monitor gateway
Traffic monitor triggers on size & time (assuming large data)
Unusual database queries

All of these mechanisms can be defeated with sufficient access. Fundamentally you are asking about Insider Threat. There are whole industries marketing tools that claim to detect anomalous activities and insider threat patterns. Depending upon details and environment, some of these tools can work fairly well, none are perfect.


Is it possible to implement a nonce without storage?

From the question: "because the request should not occur twice."

No storage means no sense of history which is necessary for your requirement that something shouldn't occur twice.  So the answer is no.  If you want your server app to remember what happened in the past it has to be able to store that somewhere.

You could implement a nonce that was time-limited and not use-limited and that you can do without server-side storage.  You just attach a timestamp to the nonce (and sign it, so the server can verify and attackers can't forge) and stop honoring it after X seconds/minutes/hours.  Replay attacks would be possible but only in that time window.

Your server also needs a trusted source of time.  If an attacker can make your server think it's yesterday then nonces from yesterday start working again.


A BadUSB device can simulate an HID (human-interface device) such as a mouse or keyboard without breaking functionality. Such a device could easily be made which both executes programmed functions and works as a real mouse. In fact, even a flash drive could do that, by pretending to be a USB hub. That would allow it to pretend to be two devices at once, behaving as a storage device and as a keyboard.

Although, in theory, the functions should be visible, there are numerous ways to execute code through an HID without any visible interactions in the screen. You can't rely on the lack of a terminal popping up with text appearing in it as an indicator that a malicious HID is not present.


Can someone find wpa2 key through ethernet?

The key exchange is done wirelessly, not over the wire, so the wired clients are unable to intercept those transmissions. There is no reason why the AP should rebroadcast the handshake to its wired clients, so no, the scenario you describe is not possible.

Moreover, knowledge of the handshake does not allow someone to get the WPA2 key. For more on this side of things, see Are WPA2 connections with a shared key secure?


As far as I know pfsense performs very simplistic traffic shaping where by it prioritizes traffic based on port range.  This is just so that you can play games with someone else using BitTorrent on the network.  This is just to be friendly,  this is not for "security".

Trying to filter all BitTorrent traffic at the gateway is very a difficult problem and a VPN or another type of tunnel can always be used to undermine this kind of filter.


What possible security flaws might sit behind this Pokerstars' password update message?

While a definitive answer can only come from the origin of the message and the restrictions, there are some points to make.

The general idea of restricting passwords in such a way (especially with the tmp-part) suggests something is not as it is supposed to be and hinting at plain text passwords. Yet for the benefit of the doubt, they might use a special hashing scheme that hashes the first three characters of the password separately, allowing them to check for temporary assigned passwords.

This might pose a threat, depending on what comes after the tmp part: if thats just 5 numbers, the search space for enumeration on such passwords is tiny, for example.

In any case, this restriction hints at them using passwords to store information that does not belong there (but in a separate field in the database) - and while it doesn't have to pose a threat by itself, deploying such techniques is generally a sign for bad software engineering.

This by itself can pose a threat: Bad software developers are more likely to make mistakes on many levels that only wait to be found and exploited.

Whatever might be the reason for them to deploy this restriction, it is a sign of bad programming and/or bad software or database engineering and thus a sign of danger; you should use a disposable, strong password and basically consider the account compromised to be on the safe side.


Is SSL Interception possible without disabling Public Key Pinning on the client side?

In case of legal SSL interception the proxy CA which is used to issue the certificates for the intercepted connections gets explicitly imported into the browser/OS as trusted. In such a case browser will ignore both the builtin pinning and also the pinning done with HPKP header. This is explicitly done this way to make legal SSL interception (in firewalls, for security reasons) possible. Which means there is no need to disable public key pinning in such cases.


Can the random keys generated during handshake be guessed

You are misinformed: normal PRNG do not use only the current time as seed. Indeed, if they would just do that, then the weakness you allude to would be glaring. In fact, it indeed glared, back in 1996: the then-leading Web browser, Netscape, was using a combination of the current time and its process ID as seed for its PRNG.

Nowadays, computers seed their internal PRNG with a lot of "hardware events" from which it is assumed that some entropy can be extracted. Current time is used, not as a source of randomness (it is not random), but as a way to measure the events. For instance, one can time (to the nanosecond, using the CPU cycle counter) the moment that any hardware interrupt occurs; since key strokes and mouse movements trigger IRQ based on the biological user of the computer, the exact times at which these appear are deemed unpredictable by adversaries.

Other sources may include, for instance, webcams: a picture from a webcam, even facing a blank wall, has a bit of thermal-induced noise which will alter the least significant bit of some pixels. Such noise is stochastic in nature, and gain defies predictability.


What tools are available for distributing and syncing firewall rule-sets to multiple devices?

A couple engineers I know are using puppet to maintain iptables rule sets.

http://projects.puppetlabs.com/projects/1/wiki/Module_Iptables_Patterns
https://github.com/camptocamp/puppet-iptables


Would encrypting a signed JWT prove viable to secure claims payload?

I believe you are asking two questions:

does changing payload invalidate signature: TL;DR: yes
does adding encryption over JWT give you authenticity of content: TL;DR:  don't encrypt yourself, use JWE!

Here are the answers in more detail:

(1) According to the specifications,
https://www.rfc-editor.org/rfc/rfc7515.txt

the signature of a signed JWT (JWS) is computed over the protected header as well as the payload:

(see section 5.1.  Message Signature or MAC Computation)

Compute the JWS Signature in the manner defined for the
       particular algorithm being used over the JWS Signing Input
       ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
       BASE64URL(JWS Payload)).

So changing the payload should invalidate the signature.

(2) Do NOT encrypt your own JWT!! There is an actual specification that defines how to encrypt JWTs (called JWE):
https://www.rfc-editor.org/rfc/rfc7516.txt

JWE uses authenticated encryption which means that the plaintext is first encrypted and then an integrity check is produced over the ciphertext.
You can get more info on what the plaintext looks like from Section 5.1 of above Spec.

It is possible to securely store access policies in the payload of your JWT if you use either encrypted or signed formats. You may want to use encrypted if you don't want the client or other parties to have any knowledge of the policy data. If you don't care who can read it and you only care about who can change the values, use signatures only.

Remember though that the more security you add, the bigger the performance impact so use your judgement on what is needed.

Final note: Key management of the signature and encryptions keys also becomes an important issue for you to consider, because at the end of the day, whoever has access to the keys can decrypt your JWE or modify the signature of your JWS. So make sure you use good safety practices in where you store the actual keys, who has access to them and how they are used and kept in memory.


Does CVE-2017-9445 also effect Ubuntu 14.04.X and 16.04.X?

The first link from you clearly says (contrary to your claims) that 14.04 and 15.04 are not affected, that patches for 16.10 and 17.04 have been released and that patches for 16.04 are needed.

It also says in the notes that the affected systemd-resolve is not used in 16.04 (Xenial) by default and will only be started is the user executes it - but this should at most affect the specific user and not the system. That's why patches for 16.04 are not that critical as they were for 16.10 and 17.04 where systemd-resolve is run by default.


The OTP should integrate with your RADIUS server. I guess you are using NPS?
The SafeNet Authentication Manager integrates with NPS and you can use different kind of OTP tokens (preseeded and seedable tokens).

You can seed the eTokenNG OTP, i.e. you write the secrets on the tokens yourself.


Is IP whitelist sufficient to protect a server?

IP spoofing only works for incoming, UDP traffic. If you need the return trip to work, network layer IP spoofing doesn't work any more.

While white-listing is a good defence in depth strategy and mitigates against many attack vectors, some attack vectors still remain, like MITM attack.

The traffic between the two servers can still be intercepted and modified (MITM attack). You need to use secure connections like SSL/TLS, IPsec, VPN, etc.