My DNS Name Server does not support DNSSec client queries, what alternatives do I have?

You may have to clarify what it is you mean when you say that your current nameserver doesn't support DNSSEC when you're speaking from the resolver perspective. You see, any nameserver (that will do recursive queries for you) will cache and forward any record set your request. That includes RRSIG records which are the foundation of DNSSEC.

Examples:

http://www.digwebinterface.com/?hostnames=www.isoc.org&type=ANY&ns=all

http://www.digwebinterface.com/?hostnames=www.isoc.org&type=RRSIG&ns=all

You can run a DNS resolver on your own machine that rejects invalid DNSSEC records. It is the local resolver's job by default, however. No special configuration is needed for nameservers to support this.


Kerberos is designed to provide secure authentication over insecure networks, and uses pre-agreed (during enrolment) or randomly generated symmetric keys to encrypt data between the KDC and the client.
Provided your choice of encryption algorithms are sound, this will ensure that an attacker cannot decrypt the data without brute-forcing the encryption algorithm.

Kerberos can use a variety of cipher algorithms to protect data. A Kerberos encryption type (also known as an enctype) is a specific combination of a cipher algorithm with an integrity algorithm to provide both confidentiality and integrity to data.
Clients make two types of requests (KDC-REQ) to the KDC: AS-REQs and TGS-REQs. The client uses the AS-REQ to obtain initial tickets (typically a Ticket-Granting Ticket (TGT)), and uses the TGS-REQ to obtain service tickets.
The KDC uses three different keys when issuing a ticket to a client:

The long-term key of the service: the KDC uses this to encrypt the actual service ticket. The KDC only uses the first long-term key in the most recent kvno for this purpose.

The session key: the KDC randomly chooses this key and places one copy inside the ticket and the other copy inside the encrypted part of the reply.

The reply-encrypting key: the KDC uses this to encrypt the reply it sends to the client. For AS replies, this is a long-term key of the client principal. For TGS replies, this is either the session key of the authenticating ticket, or a subsession key.

MIT Kerberos Documentation


Should it remain as a general advice to encrypt the whole HDD?

That's not how full disk encryption works. Corruption of one bit of ciphertext will only corrupt a single disk block (usually 512 bytes). See https://en.wikipedia.org/wiki/Disk_encryption_theory. Most modern FDE schemes use XTS mode.


Is there any way to list the contents of the iPhone/OSX Keychain and their security level?

On mac os x, you can view the keychain items by opening the Keychain Access application.

On the iphone, keychain dumper can be used to dump all the keychain items. But it only works on jailbroken phones. To know more on usage of keychain dumper visit - http://www.securitylearn.net/2012/03/27/keychain-dumper-usage-explained/


Can someone redirect or block emails of a specific sender?

Sure, any email relay in the chain can block emails.

Are they doing this, specifically, to craft your experience? Very highly unlikely.

Before jumping to malicious conclusions, make sure that you have exhausted all technical conclusions first.

Make sure that you check all the normal things like your junk/spam folder and any custom email handling rules.

Email rules brings up the one idea that could be malicious: someone might have gained access to your email account and set up rules. But this is not about some external email system, this is a targetted attack. Unlikely, but possible.

So, check those things on your end, then set up another email account and have them try that instead. All the normal email troubleshooting stuff.


What strategy would one utilise in order to breach an entire network, after gaining access to an embedded device on said network?

Lateral movement.

When you gain administrator/root access to a device with poor security you have a feet in a network, the first thing you need to do is to backdoor the device in order to get a persistent access to the device.
Then, you can easily create a SSH tunnel between your attacking box and your target, forward multiple or all ports through the tunnel. At this point you are able to work (play) with the rest of the network.

In few words, you create a pivoting point.


Giskismet query, how to select specific data?

Analysing kismet XML is the best way to go on this one.  There's a script that I've knocked up which should do most of what you're looking for, but feel free to look through it and modify for your purposes.

I'm planning to put it in a github repo at some point, but it needs cleaned up a bit before that.  That said it should work ok for you at the moment, so here's a link to the code

you'll need to get ruby installed and working, along with the nokogiri and ruport gems.


Sign SSL certificate with root certificate using openssl

First, create the directories to hold the CA certificate and related files:
sudo mkdir /etc/ssl/CA
sudo mkdir /etc/ssl/newcerts

The CA needs a few additional files to operate, one to keep track of the last serial number used by the CA, each certificate must have a unique serial number, and another file to record which certificates have been issued:
sudo sh -c "echo '01' > /etc/ssl/CA/serial"
sudo touch /etc/ssl/CA/index.txt

The third file is a CA configuration file. Though not strictly necessary, it is very convenient when issuing multiple certificates. Edit /etc/ssl/openssl.cnf, and in the [ CA_default ] change:
 dir             = /etc/ssl/             # Where everything is kept
 database        = $dir/CA/index.txt     # database index file.
 certificate     = $dir/certs/cacert.pem # The CA certificate
 serial          = $dir/CA/serial        # The current serial number
 private_key     = $dir/private/cakey.pem# The private key

Next, create the self-singed root certificate:
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

You will then be asked to enter the details about the certificate.

Now install the root certificate and key:
sudo mv cakey.pem /etc/ssl/private/
sudo mv cacert.pem /etc/ssl/certs/

You are now ready to start signing certificates. The first item needed is a Certificate Signing Request (CSR), see Generating a Certificate Signing Request (CSR) for details.
Once you have a CSR, enter the following to generate a certificate signed by the CA:
sudo openssl ca -in server.csr -config /etc/ssl/openssl.cnf

After entering the password for the CA key, you will be prompted to sign the certificate, and again to commit the new certificate. You should then see a somewhat large amount of output related to the certificate creation.

There should now be a new file, /etc/ssl/newcerts/01.pem, containing the same output. Copy and paste everything beginning with the line
-----BEGIN CERTIFICATE-----
and continuing through the line
----END CERTIFICATE-----
to a file named after the hostname of the server where the certificate will be installed. For example mail.example.com.crt, is a nice descriptive name. Subsequent certificates will be named 02.pem´, 03.pem`, etc.
Replace mail.example.com.crt with your own descriptive name.

Finally, copy the new certificate to the host that needs it, and configure the appropriate applications to use it. The default location to install certificates is /etc/ssl/certs. This enables multiple services to use the same certificate without overly complicated file permissions.
For applications that can be configured to use a CA certificate, you should also copy the /etc/ssl/certs/cacert.pem file to the /etc/ssl/certs/ directory on each server.


SSL Auth to proxy using Certificate on Client-side

Are you asking if it is possible to negate the need for "login" authentication by using certificate based authentication?

If so, then yes you certainly can provided that your users don't have roles which determine their access levels to the service (authorisation). Furthermore, you could also achieve mutual authentication so that both the server and client identify themselves as authentic (prevent man-in-the-middle attacks). I recommend that you research SSL and see what it can do for you!

I hope this is useful to you :)


How could I tunnel all actions I do in my VPS from my browser (like PHPmyadmin actions)?

Since it's SSH port forwarding, it should be encrypted. There's also a solution in which you don't use the underlying webserver or phpmyadmin, to simply forward the mysql port, such as -L 3306:localhost:3306 and connect to the database using a client such as MySQL workbench (or most IDEs have similar integrated anyways).


Is it true that key authentications are considered insecure nowaday?

Key authentication (using a cipher key, not a physical key) is a secure way to authenticate. Only your machine should have the private key needed to complete the key pair and thus authenticate.

Password authentication (using physical keys on a keyboard) is considered insecure since it can be brute-forced or someone looking over your shoulder when you type it can easily get ahold of it.

Furthermore, allowing logging in as root over SSH is considered bad practice. There is a seperate directive in the sshd config called PermitRootLogin, which is by default set to no. You should keep it that way. You should never directly login as the root user, but rather login as a local user and then switch to root using the su command or run a single command as root using sudo (given you are in the sudoers file), but only when you actually need it.

There are too many reasons not to login as root directly to list here, but for example's sake one important reason for this is that you cannot do any proper auditing on your system. When logging in as a local user first, you can then always check the logs and see who logged in prior to becoming root and thus who is "behind the root mask". Also, when using sudo, each command and the user that issued it are logged (by default). Logging in directly as root does not tell you which user ran specific commands and makes it hard to track down who did what on your system.


How is the bitcoin block header data padded for SHA256 hashing?

According to section 5.1.1 of FIPS-180-4, SHA-256 messages are padded with a binary 1, followed by a number of 0s, and finally a 64-bit binary representation of the length of the message:

Suppose that the length of the message, M, is  bits. Append the bit "1" to the
end of the message, followed by k zero bits, where k is the smallest, non-
negative solution to the equation  + 1 + k ≡ 448 mod 512. Then append the 64-bit
block that is equal to the number  expressed using a binary representation.

This is not specific to Bitcoin, and any correct SHA-256 implementation will do this. For Bitcoin, a remaining 48 bytes of padding would be a single binary 1, a bunch of 0s, and the binary representation of the number 640 (80 bytes in bits). In binary, the remaining 48 bytes would be:

1 00...00 0110 0100 0000

Note that the SHA family of functions represent binary in big-endian format.


The good news is two-factor can be free.  Google authenticator is free and mixed with FreeRadius should work with just about any access device.

It is not as fancy or secure as RSA's or some of the others but it is pretty simple to implement and does satisfy a second factor to username and password.

From what I can tell it looks to be certificate based since it does not need a server to talk to on the authentication side, just accurate time.  It does not have the extra protection of RSA for guessing OTP's or pin's but some of that can be accomplished with intruder detection on the device utilizing the authentication.

One thing to watch for, if your using your phone to access the servers and to access the OTP for GA, I do not believe it is considered a 2nd factor from a NIST perspective, as the thing you have should be separate from the device you login from unless there is a defined trusted path.

If money is a concern, it is worth a look:)


How does formal verification guarantee secure, error-free code?

It doesn't guarantee that the code is free of vulnerability.  However, if verification is used appropriately, it can increase assurance (confidence) that the application is secure.

Speaking from a very broad perspective, there are two aspects of this problem:

Verification. Given a mathematical model of the system and a mathematical specification of the requirements, does the system meet the specs?
Validation. Do we have the right set of requirements? Does the mathematical spec accurately reflect the true requirements? Does the mathematical model accurately and completely correspond to the code?

Sometimes people focus only on verification, but both matter.

In your situation, if the specification incorporates all relevant security requirements, and if the mathematical model correctly corresponds to the code, and if the verification is done appropriately and is successful, then we may have a basis for significantly increased assurance that the system will meet our security requirements.

In the best case, verification can be a powerful tool to help assure security, one of the most powerful that we have.  However, as with anything, it is possible to misuse the technology or get a false sense of security if it is not used appropriately.  One of the most common failure modes is that the verification process does not verify all relevant security requirements (some are overlooked or omitted).

To say much more might require delving into the details of the system, the security requirements, and the nature of the verification that was done, but hopefully this gives you an overview.


How key management happens in both OpenSSL and aescrypt and how the key is stored after encryption?

If you try running the openssl command-line, you will see that it will ask for an "encryption password". That password is the key; there is no key stored anywhere else.

Looking at OpenSSL's source code (I am here looking at OpenSSL-1.0.2g, file is apps/enc.c), it appears that the password is used, along with a random salt, into the EVP_BytesToKey() function: that function generates the encryption key (and the IV) from the salt and the password, with a complicated hash-based function. The iteration count is hardcoded to 1 (which, as far as password hashing is concerned, is terrible). The output file (not counting the Base64 encoding added with the -a option) starts with a sequence of eight fixed bytes (53 61 6c 74 65 64 5f 5f) followed by the salt itself (8 bytes), then the encrypted data. Thus, the salt which was generated randomly is encoded in the file itself, but the password is not stored anywhere else than the brain of the user.

I am not aware of a standard tool called "aescrypt". Google searches show several tools with that name, so I cannot know which one you have on your machine. I bet, though, that the general principle is the same: the tool asks for a password, and derives the encryption key from that password.


If my password is not on rockyou.txt does it mean that is a good password?

TL;DR: No. it only means nobody on that list have the same password as you.

Stop right here, install a password manager, then come back.

Done? Good.

That list was from a company (RockYou) that stored all passwords in clear. No matter if someone had a 64 byte password, with a mix of symbols, letters, numbers, capitals, and unicode chars, if he had an account at RockYou, the password leaked. And that wordlist is used on lots of bruteforce tools, so it will be used on emails, routers, Active Directory accounts, and everything on the internet that uses a login and password for authentication.

That's why everyone needs a password manager. No exceptions. It solves the two most prominent issues with passwords: weak passwords, and password reuse.

If your password is weak, it was used by lots of people too. So a leak like RockYou will mean your simple password is leaked, and a service you use will probably be compromised.

If you reuse passwords, no matter how complex the password is, some day the password leaks, and every service you use can be attacked.

A password manager solves both problems: creates long, complex and unique passwords for every service, and requires you to only remember the master password. They are not perfect, they can have security issues, but not using a password manager is the equivalent of saying that bridges can collapse, so you will swim across the river.


Could I ever be legally required to decrpyt user information?

In light of the fact that you don't have the private keys (given the way that you've posed the question), it would be impossible for any authority to force you to decrypt information that was encrypted using the accompanying public keys.  You can't get blood from a stone.  But notwithstanding, authorities in the US have been known to force site operators to hand over private SSL keys - perhaps most notably in the case of Lavabit (https://en.wikipedia.org/wiki/Lavabit).

Edit:  Thinking more about this - It seems that this question begs another question.  I understand that all encryption is done at the client side by your application, and that the private keys used for encryption are stored at the client side as well (a la Proton Mail).  But, if your application were to serve some malicious client-side code, would it be possible then for your server to access the client's private keys?  If so, then it doesn't seem like it would all that much more egregious for an authority to force a site that operates in this manner to do this, than it is for an authority to force a site to hand over its private SSL keys. I believe this is one of the reasons why Proton Mail setup shop in Switzerland.


Service banner checking for vulnerabilities offline

Your proposed tool would perform a lookup of the version numbers against a database of known vulnerable versions. That could be scripted by hand and checked against something like metasploit, NSE, or exploit-db.com (if by 'offline', you mean 'away from the targets').

This would be very cursory in nature, so I doubt a tool pre-exists, but can easily be done by hand.


Is giving out login information to a read-only mysql database to the public a security threat?

Yes, of course is a potential security threat.  MySQL can always have a vulnerability in it, perhaps something like CVE-2003-0150  MySQL Root Privilege Escalation Vulnerability from many years ago.

New flaws can be introduced with any update, and old flaws can be discovered at any time.

Just because you ask MySQL not to let the user run or create anything doesn't mean MySQL is perfectly effective at doing so at all times and after each update.

And, naturally, if then can execute SELECTs, they can execute SELECT with a cartesian product large enough to choke your server completely via IO and/or CPU load, or use up as much of network bandwidth as they can obtain.

This is not even counting possible fun with transaction isolation level to try and cause locking and deadlocks.  Watch out for temporary tables as well, of course.


What is gained by hashing the last block on-device?

Citing from Smart card handbook By Wolfgang Rankl, Wolfgang Effing

The HASH option of the PERFORM SECURITY OPERATION command can be used to compute a hash value. The command may transfer either the data to be hashed or a hash value already computed outside the smart card along with the data needed for the final step of the computation. In the latter case, the hash computation for the final block is performed in the card. The advantage of the latter method is that the hash value can be generated significantly faster outside the card, but the final step still occurs inside the card. From a purely cryptological perspective, this provides only a small amount of extra security, but it does somewhat limit the possibilities for manipulating the hash value. For this reason, it is widely used in practice.

Last block of hash usually contains data length ("data needed for the final step").
This blog describes all modes of PERFORM SECURITY OPERATION:HASH command. They are: hashing everything on smart card; hash last part of data (he says nothing about length of this pard); don't hash anything, just do a signing.
This article says:

Let us point out that, for performance reasons, the hash function is generally
performed outside the card. In particular, when the digital signature function
is a keyed-MAC function, only the last block computation is performed on the
card.


What question(s) can someone ask an individual to quickly determine their 'hacking ability'?

Jack sits back, Reflects his thoughts for the moment, Scratches his head wondering if you mean the magic bytes that would be used by file(1), the signature of the internal fs, the UUID of the device... and how to phrase it to be understood by Diane.

Jack - "What do you mean. What's that?"

  Diane thinks Jack has absolutely no idea and proceeds with the transaction.

Alternatively, suppose you confirm that Jack is a complete noob. However,

... his ex-girlfriend Eve put a trojan horse there before giving it to him.
...he is so incompetent at handling computers that his Desktop got infected and malware spread to the eBook.
... he bought it from Mallory who did something malicious to it.
... he is the lower rank from a criminal gang selling infected ebooks. He only sells them, and has no idea on how they were infected.¹

And all these scenarios assuming Jack is indeed caught off-guard, has an honest reaction and you are able to accurately discern it.

Really, if you are concerned about the device old contents, you should do a factory reset of the device. That will wipe it.

(Not the kind of answer you were expecting, but should serve you better)

¹ Just kidding. If the deal is too good to be true, then the catch is unlikely to be because they infected the ebook reader² (with which goal? to get a copy of 50 shades of grey from you?). I would expect that the device does not exist, is counterfeit, stolen, broken... Those would be easier ways to make money (for a criminal) selling readers.

² I assume you are not Angela Merkel aide.


When encrypting cloud-stored data, is it acceptable to use the user's account password?

If you do the encryption and decryption on the server-side, there is always a chance for an administrator to decrypt the data without the knowledge of the user, by modifying the system so that when a user legitimately decrypts his or her data, the decryption key is stored to be used at the leisure of other interested parties, for instance, in the service of warrants.

That said, the scheme you describe is generally along the lines of how systems like this are in fact built, and in normal use, are reasonably secure.   There are a couple of caveats, or clarifications, however.

You would not use the password directly as a key.   You would use a PBKDF such as bcrypt, scrypt, or PBKDF2 to turn the password into a strong random key using as high a work factor as makes sense for your application.
You would generally not use this key to encrypt the data directly.  You would generate a strong random key on the server that will be the actual data encryption key (DEK).  The key derived from the password will then be used as a key-encryption-key (KEK) to encrypt the DEK.  This way, if a user decides to change their password, you generate a new KEK, and you only have to re-encrypt the DEK, and not all of the data.
With this system, you're not actually required to store a password hash at all.  When a user logs in, you merely need to derive the KEK, decrypt the DEK, and determine if it can correctly decrypt data for the user.  If it can, the password is correct.  If not, it isn't, and you can fail the authentication attempt. This may or may not be desirable depending on the application.


In Tor, what stops the end server from following the breadcrumbs back to their origin?

As others have pointed out, "knocking on people's doors" can be difficult when the said doors are spread over the World, in locations which are geographically remote and, more importantly, legally remote. If all the Tor nodes are under in scope of a single law enforcement agency (e.g. they are all in China, or all in the USA), then that agency may indeed knock on all doors and have them opened. In an international context, this becomes harder.

Further complicating the issue is that "honest" Tor nodes (those who follow the protocol faithfully) do not keep logs, so even if they want to comply to a demand for information on a past connection, they simply do not have it any more.

Breadcrumb following is not the only way to unravel Tor, though. As the metaphor goes, if Hop-o'-My-Thumb had been smarter, he would not have brought bread, but a compass. In the case of Tor, information can be obtained by correlation in time and size. When a Tor connection occurs, the data goes through a randomly chosen sequence of nodes; as the theory goes, as long as one of these nodes is honest, the original client cannot be traced back. Or can he ?

If the evil attacker runs several nodes (and I expect big agencies to actually run a lot of Tor nodes, if only to remain "in the loop"), then it may happen that both the entry node and the exit node are attacker-controlled. These two nodes can then notice the case when a data packet entered the entry node, and a packet of the same size exited the exit node a few milliseconds afterwards. A normal connection entails several successive packets back and forth, further strengthening the correlation. The exit node can see the packet contents (and, at least, their final destination), while the entry node knows the client's identity (well, at least its IP address). That's all that is needed to destroy anonymity -- and that attack works regardless of the honesty of the nodes in between, in flagrant contradiction with the overoptimistic theory alluded-to above.

("One honest node is sufficient" is the theoretical framework for Mix networks as used in electronic voting protocols -- but that works only in the context of voting, where a node can accumulate all packets and send them en masse at the end.)


1) ASV scans, while part of PCI compliance, do not make you PCI compliant.  You also need a valid SAQ or passing audit by an approved QSA, depending upon your volume.

2) I'm not aware of any PCI-approved logo or seal.  In general, PCI compliance is a matter for direct relationships, e.g. you need to give your processor a copy of your scans and your SAQ or your AOC and ROC.  You can look up your processor in the Service Provider Listing.  Seals don't mean anything because anyone can put them up.

The acronyms:

ASV - Approved Scanning Vendor
QSA - Qualified Security Assessor
SAQ - Self Assessment Questionnaire
AOC - Attestation of Compliance, what your QSA gives you.
ROC - Report on Compliance, what your QSA gives you.


Can a weak password generate the same hash as a strong password?

A bcrypt hash is 184 bits, so there are 2^184 possible hashes. That is way more than the number of atoms in the earth. You picking a password with a hash that matches another hash is like me picking a random atom in the earth, and then you by accident picking that exact same atom! You are literally more likely to die from a comet hitting earth tomorrow.


How are Windows 10 hashes stored if the account is setup using a Microsoft account?

Windows hashes are saved in SAM file (encrypted with SYSTEM file) on your computer regardless of the fact that you are using Microsoft account. It needs to be done this way to allow you to log in to your computer, even if you are not connected to the internet. If you change your password using account.microsoft.com, you will still be able to log in to your computer with your old password (even if you are using Microsoft account). After logging in to the system, you will be prompted to type new password, but as long as you don't type new password, you will be able to use old password to log in to your computer. After you type new password, SAM (and possibly SYSTEM) file will be updated.

You (wrongly) get 31d6cfe0d16ae931b73c59d7e0c089c0 hash of your password because format of the SAM and/or SYSTEM files has changed since Windows 10 Anniversary update (see: similar problem), thus tools like chntpw, bkhive, pwdump, samdump2 print hash of the empty password (I verified it on my Windows 10). Since this update, Windows uses AES128 to encrypt password's MD4 hash. Because of that, nearly all tutorials regarding Windows password recovery became outdated.

Fortunately there is a tool called mimikatz (Windows-only, but can be ran on Linux by using Wine) created by Benjamin Delpy, that can read passwords' hashes saved in Windows' new format. Note that Windows Defender and Symantec antivirus treats it as a 'Hack Tool' and removes it, so you need to disable them before running mimikatz (run as a administrator).

mimikatz consists of many modules, but you should explore lsadump module, particularly lsadump::sam function.

Excerpt from docs:

  If you're not SYSTEM or using an impersonated SYSTEM token, you'll have access denied error:

mimikatz # lsadump::sam
Domain : VM-W7-ULT-X
SysKey : 74c159e4408119a0ba39a7872e9d9a56
ERROR kuhl_m_lsadump_getUsersAndSamKey ; kull_m_registry_RegOpenKeyEx SAM Accounts (0x00000005)

  In this case, you can use psexec to begin SYSTEM (or other tools) or elevate with token::elevate command to impersonate a SYSTEM token:

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # token::whoami
 * Process Token : 623884       vm-w7-ult-x\Gentil Kiwi S-1-5-21-1982681256-1210654043-1600862990-1000  (14g,24p)       Primary
 * Thread Token  : no token

mimikatz # token::elevate
Token Id  : 0
User name :
SID name  : AUTORITE NT\Système

228     24215           AUTORITE NT\Système     S-1-5-18        (04g,30p)       Primary
 -> Impersonated !
 * Process Token : 623884       vm-w7-ult-x\Gentil Kiwi S-1-5-21-1982681256-1210654043-1600862990-1000  (14g,24p)       Primary
 * Thread Token  : 624196       AUTORITE NT\Système     S-1-5-18        (04g,30p)       Impersonation (Delegation)

mimikatz # lsadump::sam
Domain : VM-W7-ULT-X
SysKey : 74c159e4408119a0ba39a7872e9d9a56

SAMKey : e44dd440fd77ebfe800edf60c11d4abd

RID  : 000001f4 (500)
User : Administrateur
LM   :
NTLM : 31d6cfe0d16ae931b73c59d7e0c089c0

RID  : 000001f5 (501)
User : Invité
LM   :
NTLM :

RID  : 000003e8 (1000)
User : Gentil Kiwi
LM   :
NTLM : cc36cf7a8514893efccd332446158b1a

You can download x86 and amd64 binaries of the mimikatz here.

As a side note – if you want to make sure that password's hash is hash of your password, you can easily do it using Python:

user@mycompa:~$  python3
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, binascii
>>> passwd = "password"
>>> hash = hashlib.new('md4', passwd.encode('utf-16le')).digest()
>>> print(binascii.hexlify(hash))
b'8846f7eaee8fb117ad06bdd830b7586c'


Media players often connect to the internet today, for example to get album covers, lyrics, new music (when streaming) or similar. This functionality can have bugs which might result in remote code execution, i.e. a take over of your system by the attacker. And, remote execution can include starting the browser with a specific URL which then might result in hijacking the browser for other purposes.

If you want to really be sure that no remote attacker can take over your system through the media player make sure that the system has no internet connection and does not run any content which might have been compromised by an attacker, like previously downloaded playlists, music or similar.


Are VIA CPUs vulnerable to Spectre/Meltdown attacks?

VIA's global market share in below 1%, therefore they are not even mentioned.

As the "VIA Nano" generation from 2008 onward, is able to do out-of-order execution (https://en.wikipedia.org/wiki/VIA_Nano), it could be highly possible, they are affected as well.

With respect to their ARM-based products, Cortex A8 and A9 were used there, so they would be vulnerable.


Auditing Sysmon 10 DNS events on Windows 2008 R2

According to Sysmon Documentation,

Event ID 22: DNSEvent (DNS query)
This event generates when a process executes a DNS query, whether the
result is successful or fails, cached or not. The telemetry for this
event was added for Windows 8.1 so it is not available on Windows 7
and earlier.

This explains why you don't see event 22: Windows Server 2008 R2 and Windows 7 share the same version number 6.1, whereas the equivalent for Windows 8.1 is Windows Server 2012 R2 (version 6.3).


Is there a repository with different ssl related files for testing purpose?

Frankencerts?
There was some research on mutated/misencoded "FrankenCerts" ("Frankenstein Certificates").

The paper is here: Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations
And also: "A package containing 357 mucerts that can trigger validation discrepancies among OpenSSL, PolarSSL, and GnuTLS can be downloaded here"

OpenSSL Test cases?
OpenSSL has several test certificates on board as part of internal test harness. (And I assume that all other TLS libraries have a similar stash of certs.)


How can a manager delegate work to their PA if password sharing is not authorised?

In many e-mail systems, one can delegate another to act on their behalf.  So Pat, the secretary, can send mail on Terry (the boss) behalf.  In Outlook, for example, the email says "from Pat on behalf of Terry".    Additionally, cloud storage and other accounts can have multiple permissions on accounts/directories, access. So Terry can grant Pat access to any directory desired.  Of course Terry should be careful to not grant too much access, lest Pat get access to Terry's personal files, which quite often contain subordinate payroll information and other confidential documents that no one else should see.

This type of delegation has happened in every company I've ever worked for, and I'd imagine that any IT person who's been in the business for a short time would know how to handle delegation.  That way you still have traceability from shared access without sharing a password.

Think of it this way: suppose Pat could just log into Terry's e-mail.  Then an e-mail comes out: Pat has done a fantastic job.  HR: please immediately send me paperwork granting a 10% raise.  Who sent it?  You can't prove anything; both parties deny it.  By using delegation, we can see that Pat has indeed done a fantastic job and deserves a nice pay bump.


Can I safely and securely store hash(sessionId) in application logs?

If session identifier is randomly chosen from sufficiently big space (something like 12 bytes should be more then enough) then any non-invertible hash function (even md5) will be secure, and there will be no need for salt (rainbow tables of this size are infeasible).

To expand, problem when storing password hash is that passwords usually have very low entropy (unlike tokens, like session id for example). Besides, you do not care for other hash function properties in which md5 considered weak - attacker cannot influence his session id to collide with any user, and even if he does it will only (at best) confuse you studying the logs).


First, please read upon session fixation attacks and make sure you understand how they work.  You didn't give us the information that is needed to determine whether standard session fixation attacks will work; all of that information is relevant to other attacks, but not to session fixation.

The fundamental characteristic of a session fixation attack is that the attacker manages to enroll the victim into a session that was previously established by the attacker.  After this, the attacker has control of a session that is now being used by the victim as well, which may enable the attacker to do all sorts of bad things.

The primary precondition for a session fixation attack to be possible is the attacker has to be able to force the victim to start using a session ID of the attacker's choice.  On some web sites, this is possible if the attacker can get the victim to visit a link like http://yoursite.com/?SID=1209023, because the web site will automatically assign the victim session ID 1209023 for the victim's future browsing on the site.  On other web sites, this is not possible, because the web site doesn't work that way.

So, you haven't given us enough information to know whether session fixation attacks will work, because you haven't given us enough information to determine whether the precondition is met.

That said, the site almost certainly has security problems.  It is vulnerable to eavesdropping (Firesheep-like attacks) and likely vulnerable to login CSRF.


Two solutions for CSRF on OWASP for ASP.NET WebForms

The tricky part for me, at least, is to construct a successful/working example CSRF attack, then it is trivial to implement both approaches and see them in working and actually mitigate the CSRF attack.

The first approach, using ViewStateUserKey only, seems not been affected by turn off enableViewState, either in page level or in web app level. As hidden ViewState is still in the rendered HTML, and the process of encoding ViewState is still in place so that you can not turn off ViewStateUserKey by simply turn off ViewState.

On the other hand, as the second approach is using ViewState for the storage of AntiXsrfTokenKey, it will stop working if the ViewState is disabled. So the comments from that OWASP page are wrong, or at least, misleading, the other comment from OWASP other page is much better and clearer.


One certificate for both client and server authentication

From a normative point of view, RFC5280 does not put any constraint on having both extended key usages set at the same certificate.

From the security point of view, there is also no crypto/protocol problem (as far as I know/could find) on using the same certificate for SSL authentication as client (I guess for connecting to other services) and server (for receiving connections). Since if you use two certificates both would also be stored on the same server, if an attacker can steal one certificates he can steal two, no gain or loss there.

However, it does not hurt to keep them separate too, specially if for any reason later on you need to change one the certificates characteristics in a way that could affect the functionality on one of the usages (ex: change the DN to include something relevant to the client auth that could break the server auth).

I always, in such situatins, keep both separate, and if you are talking about private PKIs, usually I also use different CAs for issuing each of them.


Timing attacks are a type of side channel attacks. From a formal point of view, a cryptographic algorithm (let's say an encryption system) takes some input and provides some output, and the attacker sees the two values and tries to work out the key from these values. However, in a realistic system, the algorithm does not happen "magically": it has to run somewhere, on a computer or some other circuitry, and the attacker may try to observe from the outside this operation and deduce some extra information.

A timing analysis (or attack) is about measuring the time taken by the cryptographic algorithm to execute a given operation. Informally, the attacker tries to make "informed guesses" which look like "mmh... the algorithm took 174 nanoseconds to execute, but if that key bit was a 1, it should have taken at least 176 nanoseconds, so the key bit was a 0".

Defence against timing attacks include tweaking the algorithm implementation so that it always executes in a fixed amount of time regardless of the key value and input data; or "randomizing" it so that the attacker can no longer make such guesses. E.g. with the core exponentiation of RSA, instead of computing md mod n (n is the modulus, d is the private exponent), the implementation generates a random value r modulo n, then computes re mod n and 1/r mod n, and computes ((m*re)d) * (1/r) mod n. This is called masking. Since a new r is generated for each RSA computation, this process effectively prevents the timing-based guesses from the attacker.


Why can't an anonymous server request a client certificate?

In order to answer this I think it is important to look at the definition on what is a client according to the spec. In the Glossary a client is defined as

  The application entity that initiates a TLS connection to a
        server.  This may or may not imply that the client initiated the
        underlying transport connection.  The primary operational
        difference between the server and client is that the server is
        generally authenticated, while the client is only optionally
        authenticated.

This means that servers should always be authenticated and hence un-authenticated servers ( or anonymous servers) cannot ask for client authentication. In other words, since the client is initiating the TLS connection, the server should authenticate itself to the client before authenticating the client. I think the language could be clearer so there is no ambiguity.

In your comment you mentioned reversing the roles, so the TCP server becomes the TLS client and the TCP client becomes the TLS server. This is possible using some clever socket level programming. Take a look at STARTTLS which can be used to upgrade a plain connection to a TLS connection in a standard way. Netty is a Java library that provides such an implementation of StartTLS.


How to perform a port scan against a target with a software-based firewall?

In this case the firewall isn't blocking the port scan (although some firewall products do attempt to detect and block scans). It is actually blocking the service from being available externally. The port scan can't see it because to the external world it is not there.

The port reports filtered because the firewall drops the incoming SYN rather than reply to it.

Port 445 is used for Microsoft Directory Services - which is part of the underlying mechanism for File and Printer Sharing. Were you to enable the "File and Printer Sharing (SMB-In)" Allow rule you would likely find the port started to show up.


Since you asked in a security forum, mag stripe cards are considered wildly insecure. They’re easily clone-able, which data is easily read and written to. The data on the card is static and pretty much free for all.

However, you might consider a cocktail club a relatively Low-value target, and can generally accept this risk given chip cards are way more expensive to both print and process.

For more details, typically card data is encoded onto the ‘tracks’ of a mag stripe card, with some details here. I’d bet you can buy off the shelf electronics to both process and handle magstripe cards anywhere.


I think that you are confused about how password managers work. You mention using an email recovery option, that's just not possible with any serious password manager. A password manager service doesn't know your master password, so they can't give it back to you in an email. It's just impossible.

Some password managers support emergency access (eg: LastPass's emergency access) that give other users delayed access to your vault. This allows you to give someone access to your vault after you haven't logged in for a few days. Note that this may not include recovering the master password (LastPass doesn't support password recovery), but it does give access to the vault contents. Using such a recovery method, you could store your master password in your vault and rely on the trusted person and delayed emergency access to recover the master password.

The emergency recovery strategy is similar to using another person's vault to store your password, but it adds a delay. This has pros and cons. If you need the password quickly, the delay is a hassle. But if the other person's password vault is somehow compromised, the delay gives you time to revoke emergency access before yours is compromised too.

If you do want to use paper as a backup of your master password, store it somewhere secure - like a safe deposit box. While that doesn't provide instant access, it reduces the chance of the paper being viewed by an attacker to near zero.

The easiest solution is, of course, to just not forget your master password. Personally, I write my master password down when I change it, carry it with me for a few days, then securely dispose of it (consider fire) once I have it memorized. I've never forgotten it (though I do have emergency recovery set up).


How to improve security of a stored password?

There are a couple ways this problem is approached.  One is to configure the system to connect to a PKCS#11 server, and to use the HSM to decrypt the master password when the application service is started. (This becomes another chicken-and-egg problem when you realize you have to store the PKCS#11 credentials in a file.)

Another approach is to require a human to enter an "unsealing" password every time the service is started.  While this can be more secure, it can't provide automatic recovery in the case of a failure.

Yet another approach is to store your master key in an on-board Hardware Security Module (HSM), such as a TPM chip.  You would have to consult your OS documentation for information about using this approach.


How come PBEWITHSHA256AND128BITAES-CBC-BC violates the 128 bit key limit?

If you are using a password longer than 16 bytes (without the JCE Unlimited Strength Jurisdiction Policy files installed), this can cause an InvalidKeyException. For PBE ciphers, the key is derived from the password during cipher.init() but after the key length check is done. That means the raw password is provided to the cipher in place of the key, and the password length exceeds the max key length at the time of the check. I discovered this with further documentation here.


How to you manually decrypt a SOAP message using openssl?

(It is not "hex", but Base64. Not a critical point here, but if you get the terminology right then it becomes easier to search for solutions on the Web.)

When doing symmetric encryption, openssl enc, the command-line tool, uses its own non-standard, OpenSSL-specific format which does not match what SOAP uses. OpenSSL adds a specific header (that's the "magic number" it is complaining about) and some randomness (a "salt" -- salts make a lot of sense when keys are passwords, but that's not the case here). According to the specification, encryption with AES-256-CBC in SOAP simply adds the IV as the first 16 bytes, and there is no header and no salt. This means that the following should work (I have not tried):

Extract the IV:

dd if=messagebody.bin of=iv.bin bs=16 count=1
Convert the IV to hexadecimal (real hexadecimal this time, not Base64):

ivhex=$(od -t x1 -w iv.bin | sed 's/^[0-9A-Fa-f]*//' | sed 's/ //g')
Extract the actual encrypted data:

dd if=messagebody.in of=edata.bin bs=16 skip=1
Apply decryption with explicit IV, and instructing OpenSSL not to play its own non-standard games with salts:

openssl enc -aes-256-cbc -iv $ivhex -kfile sessionkey.dec -nosalt -in edata.bin -out cdata.bin

The last remaining thorny issue is the padding. OpenSSL, apparently, uses PKCS#7 padding, which means n bytes are appended to the data upon encryption, so that:

n is between 1 and 16 (at least one, at most sixteen added bytes);
the total padded length is a multiple of 16;
the n added bytes all have value n.

SOAP, on the other hand, mandates something similar, except that they only require that the last added byte has value n; the n-1 other bytes can have any value. Thus, when OpenSSL will decrypt the data, it might find a padding which is not exactly what it would expect (it depends on whether OpenSSL insists or not on all padding bytes having value n, and on what padding byte values were used by whoever produced the encrypted data in the first place).

If padding seems to be an issue, try adding the -nopad option to the openssl enc command; then you will have to inspect the obtained binary data (e.g. with od), and remove the padding bytes yourself (again, with dd).

(All of the above has been written assuming a Unix-like system, e.g. Linux or FreeBSD.)


Questions on TLS 1.2 RFC - Clarification or references needed

First, 7.4.1.1 states:
   Each cipher suite defines a key
   exchange algorithm, a bulk encryption algorithm (including secret key
   length), a MAC algorithm, and a PRF.  ....

  My naive understanding is that all the algorithms required are right here in this exchange.

No. A (pre-TLS1.3) ciphersuite defines many of the algorithms used, but not all. It defines the ones that are in the list you quoted, and it doesn't define the ones that aren't in that list. That's rather the point of explicitly stating the list of things that are defined.

  But then comes section 7.4.1.4.1 talking about "Signature Algorithms" extension. So, a signature algorithm can be specified through an extension. But a paragraph later in the same section states:

  The semantics of this extension are somewhat complicated because the
   cipher suite indicates permissible signature algorithms but not hash
   algorithms.  Sections 7.4.2 and 7.4.3 describe the appropriate rules.

  So, does it mean that the Signature-algorithms extension is used to specify the Signature Algorithm from a set of signature algorithms selected by the server from a possibly bigger set offered by the client in the Client Hello?

Kind of. There can be and often is more than one signature used, and thus possibly more than one signature algorithm used. Each signature must meet both the constraints given by the ciphersuite, where applicable, and the sigalgs extension, if present. As it says, these are detailed in 7.4.2 and 7.4.3.

  What does 7.4.2 refer to, in relevant part? It gives permissible mappings between Key Exchange Algo and Certificate Key Type.

So it does, and immediately afterward it says

   If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.  Note
   that this implies that a certificate containing a key for one
   signature algorithm MAY be signed using a different signature
   algorithm (for instance, an RSA key signed with a DSA key).  This is
   a departure from TLS 1.1, which required that the algorithms be the
   same.  Note that this also implies that the DH_DSS, DH_RSA,
   ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
   algorithm used to sign the certificate.  Fixed DH certificates MAY be
   signed with any hash/signature algorithm pair appearing in the
   extension.  The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
   historical.

(You quoted part of this as being in 7.4.3, but it's not, it's in 7.4.2.)

Thus the keyexchange in the ciphersuite controls the type of key in the server (EE, leaf) cert, but not the signature on that cert by the CA, which depends primarily on the type of key used by the CA and not the type of key used by the server. In addition, the simplified model often presented that the server cert is issued/signed by a CA trusted by the client is just that, simplified. In practice there are nearly always two levels of CA and sometimes more; this is indicated, though not really explained, in the description of certificate_list about a page earlier in the same section:

      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.
      ... the root ... MAY be omitted ....

Sigalgs constrains the signatures on all the certs in the chain -- possibly excepting the root, because the root signature is a dummy self-signature that needn't be checked -- and the keyexchange/ciphersuite does not.

Aside: after not having a cert/key at all, this is probably the thing server admins, operators, and programmers screw up most often. You can find lots of Qs on several Stacks about 'TLS doesn't work' which turns out to be the server not correctly sending chain certs, usually because it's configured wrong. Because it is so common some clients, especially web browsers, try to work around it and often succeed, which causes people to misunderstand and even disbelieve the problem: "My server can't be wrong, because $thing works!" "Yes $thing works AND your server is still wrong". TLS1.3 (RFC8446) relaxes this slightly -- the server is still supposed to send the full chain optionally omitting root, but is not required to do so in strict sequence.

  To make things more confusing for me comes Section 7.4.3:

  The ServerKeyExchange message is sent by the server only when the
    server Certificate message (if sent) does not contain enough data
    to allow the client to exchange a premaster secret.

  What exactly is this "enough data"? Does a standard (whatever that implies!) certificate not have "enough data" any way? Will the server not have picked the key-exchange-algo, when sending the Server Hello, to match the server Certificate it sent?

Literally the next lines answer your question.

      ... This is true [more data is needed]
      for the following key exchange methods:

         DHE_DSS
         DHE_RSA
         DH_anon

     [plus ECDHE_RSA ECDHE_ECDSA ECDH_anon in RFC4492,
     referenced in the next paragraph]

These key exchanges are 'ephemeral' keyexchanges -- they use a newly-created keypair for each handshake, which cannot be in the certificate because the certificate was created in advance -- often far in advance (like years). Thus the ServerKeyExchange message is needed to convey (and validate) the publickey. The server will indeed choose a keyexchange and cert-plus-static-key that are compatible with each other, as well as being permitted by the client, but most clients today will list as preferred, and most servers will choose (either on their own bat or following client preference) an ephemeral keyexchange over one that isn't, because it provides the valuable feature Forward Secrecy aka Perfect Forward Secrecy (PFS).

      It is not legal to send the ServerKeyExchange message for the
      following key exchange methods:

         RSA
         DH_DSS
         DH_RSA

      [plus ECDH_RSA ECDH_ECDSA in RFC4492]

because those keyexchanges use (and need) only the publickey in the certificate. Only the first, RSA, is commonly used; the 'static' aka 'fixed' (non-ephemeral) DH and ECDH keyexchanges are mostly useless, and the former (static-DH) require a cert that can't be obtained from any known CA.

In addition to the publickey (and mostly certificate) based keyexchanges defined in RFC5246 (and 4346 and 2246) and RFC4492, there are some other keyexchanges defined in other RFCs like PSK (Pre-Shared Key), SRP (Secure Remote Password), and Kerberos which use ServerKeyExchange (and ClientKeyExchange as well) in substantially different ways. These are not used on the public network, and only rarely even on private networks. Consult those other RFCs for details; they can be found via the IANA registry.

In TLS1.0 (and SSL3) there were 'export' ciphersuites some of which used a keyexchange called RSA_EXPORT, which for legal reasons had the restriction that an RSA key over 512 bits could be used for signing but not encryption. This meant that if the server RSA cert key was 512 bits (or less) it simply sent the cert and the client used it, but if the cert key was longer it sent ServerKeyExchange containing a 'temporary' RSA key of 512 bits (or less) to be used for encrypting the premaster secret, signed by the (longer) key in the cert. This 'export' feature had other, also very detrimental, effects as well. See RFC2246 for the awful details.

The 'appropriate rules' in 7.4.3 are on page 52, and describe the signature in the ServerKeyExchange message, which covers the body of that message plus the session nonces, and uses the publickey in the server cert:

   If the client has offered the "signature_algorithms" extension, the
   signature algorithm and hash algorithm MUST be a pair listed in that
   extension.  ....

   In addition, the hash and signature algorithms MUST be compatible
   with the key in the server's end-entity certificate.  RSA keys MAY be
   used with any permitted hash algorithm, subject to restrictions in
   the certificate, if any.

   Because DSA signatures do not contain any secure indication of hash
   algorithm, there is a risk of hash substitution if multiple hashes
   may be used with any key.  Currently, DSA [DSS] may only be used with
   SHA-1.  Future revisions of DSS [DSS-3] are expected to allow the use
   of other digest algorithms with DSA, as well as guidance as to which
   digest algorithms should be used with each key size.  In addition,
   future revisions of [PKIX] may specify mechanisms for certificates to
   indicate which digest algorithms are to be used with DSA.

As predicted, FIPS186-3 in 2009 (and -4 in 2013) define DSA with larger sizes and SHA-2 hashes, and RFC5758 in 2010 allows them in PKIX (technically modifying 3279, not 3280 or 5280).


Understanding how does certificate validation work

Validation is about making sure that a certificate is genuine. The goal is to know whether the public key you see is really owned by the server you intend to talk to. This validation entails a lot of steps, described there in all their gory details; most of them are completely local to the client machine, so you won't see them show up in any way with network traces. In fact that's the whole idea of certificates: to allow offline validation.

There is still one step of certificate validation which cannot be really offline, which is the check for the revocation status. By definition, revocation is about cancelling a certificate that otherwise looks fine. The three main methods for ascertaining revocation status are:

CRL: a list of revoked certificate is regularly published by the CA (or another entity to which that power was delegated). The CRL is signed, and valid for some time (a few hours or days).
OCSP: an duly designated OCSP server can be asked for the current status of a certificate. The OCSP response is signed, and has its own validity dates, so an OCSP response is somehow equivalent to a CRL that talks about a single certificate.
Nothing: for a very long time, Web browsers simply assumed that no certificate was ever revoked, which sure makes the implementation much simpler.

URL for CRL download or for talking to an OCSP server are written in the certificate itself. A system that wants to validate a certificate (your Web browser; a "relying party" in X.509 terminology), and does not use the "nothing" method of revocation check, will want to download a fresh CRL or obtain a fresh OCSP response. However, it may also cache the obtained CRL or OCSP response; Windows, in particular, maintains a CRL cache that is resistant across reboots. Thus, if the browser downloads a CRL, you will see the CRL download on your network traces only once per day or so (depending on the CRL nextUpdate field). You can inspect the Windows CRL cache with certutil -URLcache CRL. Note that Firefox does its own validation completely independently of the Windows support for certificates.

OCSP stapling is an SSL/TLS extension by which a client may ask the server to send, as a CertificateStatus message, an OCSP response that establishes that the server certificate is not revoked (for now): since OCSP responses are dated and signed, how such a response is obtained has no importance. Since the server can reasonably assume that all clients that talk to it will need the verify the revocation status of the certificate that the server sends, it makes sense to use the server itself as a cache for the relevant OCSP response. It avoids the need for the client to open an extra connection to the OCSP responder, and it makes life easier for the OCSP responder too, because it just have to sign a single fresh response once every few hours.

Not all servers support OCSP stapling, which is why you won't see CertificateStatus messages for all servers.


Why did OCSP Must-Staple break BitDefender SSL interception

First of all, as it is common with TLS errors, ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome is in no way descriptive of a particular problem.

Next, I admit that I have never in my life touched BitDefender and especially its TLS wiretapping techniques with a ten foot pole, nor that I'd ever wanted to.

Having said that, I've seen a similar bug in similar products, so I may happen to give you a clue.

See, when a TLS interceptor sees a certificate, it copies it, replaces the certificate authority data with its own and signs it, and then sends to the browser (or whatever client software is trying to make a secure request). A basic TLS interceptor doesn't do anything else to the certificate: it doesn't, say, change subject alternative name field or mangle any other X509v3 extension value. Only the CA data is changed, the rest of the certificate is left as is.

As the CA data is changed, the subsequent OCSP staple won't obviously be valid, so the interceptor strips that data as well. In fact, it's acting as a proxy, so it doesn't strip anything, it just doesn't put a staple into the browser-facing connection even when it receives a staple from the server-facing connection, and that's it.

Now, the browser receives the certificate, signed by the interceptor, with OCSP Must Staple on it, but doesn't get a valid OCSP staple because it's not sent by the interceptor. At this point, the best your browser is able to do is to halt the TLS connection and display a cryptic error message.

NB: this is one way to break OCSP with a TLS interceptor that I'm aware of. BitDefender could be actually using another method, there are surely plenty of them.


HIPAA Compliance or What measures would you recommend to secure PHI for devs?

Short answer: No, developers should not be allowed acces to PHI. But in order to let them work in an environment which correctly mirrors the real world, many do!

One of the options I used to see where the organisation had the capability was to provide developers with a sanitised copy of the live database.

Obviously this takes some resource

you need a real development
environment, not just one with
pointers to a live database
sanitisation is resource heavy and
time consuming
change management around the
development and production
environments and code promotion
becomes critical

Just thought I'd update to give a little more info around sanitisation. For sensitive information this really means removing identifying information. I have seen this done by completing a full replace of names and account numbers by random (but unique) ones, or by carrying out a swap of data, so the names are no longer connected to the addresses and medical details which they started with. This is hard work - especially as you usually have to ensure the age and sex of each individual is appropriate (especially for medical databases) otherwise testing may get tricky (eg trying to track down use cases for a pregnant 90 year old man)

If your dev needs aren't as in depth, you could just provide a small database with made up data - much simpler, but not as close to real world conditions.


What are the benefits of federated identity management over bare bones public key encryption?

The simple answer is that of course you could do that but then you would have to manage the infrastructure to cope with key management, and some organisations do exactly that.

It is a challenge, though, at large scale, so why not offload some of that onto a trusted provider? That way they can focus on the identity management and you can focus on your business.

Simple outsourcing model in many respects.


Transport layer protocols like UDP, TCP, SCTP ... are traditionally implemented at the operating system kernel. While it would probably be possible to design a protocol which does encryption at the transport layer (or network layer like IPSec), adoption of the protocol would thus require changes to all relevant OS. This means adoption of the protocol would probably be very slow.

At the time SSL was invented Netscape not only created the major browser but also major server software. It was thus much easier and faster to add the protected transport directly into the application software (both client and server) instead of trying to get a maybe more academically clean approach into the various OS.

Apart from that OSI model and TCP/IP model are just abstract views to how networking worked at the time these models were created. While at this time the complexity was largely at the lower layers, the complexity today is at the higher layers and the OSI and TCP/IP model do not address today's complexity any more. Just take QUIC, HTTP/2 or even WebSockets which implement transport layer tasks inside the application layer.


I complete my own answer after a more in-depth comparison between the OSes I am the more familiar with and which have taken quite surprisingly different directions...
PID randomization was popularized by OpenBSD which added it as soon as 1997. At that time it pursued two main goals:

Protect against PID prediction vulnerabilities affecting mostly software which use the PID value to generate temporary file names. This was a common concern at that time, but today I think it would be quite rare to encounter production-level software still not using a proper method.

As a general preventive measure, "If something can be random, make it random.", encompassing putting randomness at several places in the OS (from the IP stack to the memory allocation). While some of the protection resulting from this randomness proved to be useful and became more common, PID randomization has a more troubled history.

As detailed in my question, the cure may be worse than the disease. Due to faster PID reuse, fully random PID may allow remotely exploitable flaws, while sequential PID was mainly known to allow local-only exploits.
As a side note, in an ideal world, all this should not cause any issue (yes, I talk of this ideal world where software is free of bugs and vulnerabilities). In fact these vulnerabilities usually find their root in wrong usage of the PID. Wikipedia defines the PID as being a "number used [...] to uniquely identify an active process". Therefore:

A PID is not designed to build temporary file names. Temporary files are usually created in a shared place, and that means danger! Because of this, temporary files must be created using dedicated functions which will ensure that the three required actions (checking that the file doesn't already exists, create it and set restricted access permissions) are done in an atomic (uninterrupted) way. The C language proposes mkstemp() and tmpfile(), and most Unix environments offer a mktemp command to be used by shell scripts, etc.

A PID is not designed to seed a random number generator or generate session ID or cookies. Here again you must refer to your language or environment documentation to get a proper entropy source. On UNIX systems the /dev/urandom device file is there for this purpose.

It is not by accident that Wikipedia definition explicitly states active process. On some language like C, you stay proprietary of the child process' PID until you wait for it, but this is not true for all languages (for instance in shell scripts...) and never true for processes which are not your child. In these cases the PID is just a shared resource, and you should remember that this "shared" notion implies "danger", so must therefore ensure that your take proper care and use the right functions designed to match your situation and needs.

Linux
Linux kernel main stream never implemented PID randomization, however this feature was commonly provided for several years through a security oriented third-party patch which finally decided to abandon it.
Around year 2000-2001, several people tried to implement PID randomization for the Linux kernel (examples can be found here and there), however none of these patches were accepted by the kernel development team who rejected them mostly as "security through obscurity".
However, since randomness may actually increase the global security posture of the OS and prevent some attacks, these kernel modifications finally reached their public through the third-party project: grsecurity.
This project started in 2001, bringing several new and advanced security features to the Linux kernel. It allowed to enable/disable randomized PID using a specific sysctl parameter: kernel.grsecurity.rand_pids. However, in the late 2006 (I guess - I hate news thread mentioning dates with no year!) they finally decided to drop randomized PID functionality:

grsecurity 2.1.10 was released today for Linux 2.4.34 and 2.6.19.2. Changes in this release include:

Removal of randomized PIDs feature, since it provides no useful
additional security and wastes memory with the 2.6 kernel's pid bitmap

OpenBSD
OpenBSD having initiated randomized PID functionality, it is still present for historical purposes but has no real security scope nowadays. It is up to the application themselves to ensure they correctly handle fast PID reuse.
OpenBSD aim is to encourage good development practices and thorough code security auditing. That's why they consider that it is not the responsibility of the OS to protect their users against flawed application. On the contrary an application flaw should be detected as soon as possible and corrected in the application instead of remaining hidden by OS ("The sooner we can break it, the sooner we can fix").
As a side note, while such assertion justifies itself for the base OS which is under direct control of the OpenBSD team, this becomes more disputable with third-party software:

Which do not go through the same audit as the base OS,
While OpenBSD provides and recommends the use of binary packages over ports, binary updates are only provided between OS releases for “security issues or other major fixes”.
Some software versions may be outdated. For each case this might be either a deliberate choice from OpenBSD team or a consequence of the lack of resources in OpenBSD team.

However, in this context OpenBSD team makes the assumption that, for a correctly developed and audited software, the PID generation algorithm chosen by the OS must have no impact (neither stability nor security) on the software behavior. If some software is vulnerable to an attack taking advantage of the PID being reused, then it's up to the software to be corrected, and not to the OS to ensure that the PID are not reused too quickly¹.

¹: For the curious, OpenBSD added in 2013 an hardcoded table storing the 100 lastly freed PIDs in order to limit reliability issues on low loaded systems. However, this does not constitutes a security measure since it quickly becomes effectless with higher loads, would this load be caused by genuine activity or as part of an attack.

FreeBSD
FreeBSD provides a sysctl parameter allowing the administrator to tune the PID generation algorithm from sequential to fully random. It is sequential by default.
FreeBSD implemented random PIDs in 1999 (FreeBSD 4), using OpenBSD as reference, and improved it to let the administrator set a balance between potential issues caused by sequential PID (mostly PID prediction) and potential issues caused by PID randomization (PID reuse and resource consumption).
In fact, FreeBSD design seems quite original since it is not actually the PID which is random, but the PID increment which is a random value taken between 1 and the kern.randompid parameter:

If PID randomization is disabled, then the increment will always be 1,
At maximum this parameter can be set to PID_MAX³, in this case the next PID will be fully randomly chosen.

By default PID randomization is disabled (PIDs are generated sequentially). To take effect, the kern.randompid parameter must be at least greater than 100.
If sequential PID remains a concern, I would personally recommend to set this parameter to a low value like a few hundreds: this should be sufficient to limit trivial PID prediction issues while avoiding more nasty issues caused by PIDs re-use.

³: For the purists it is actually PID_MAX - 100 to cover only non-reserved PID range, it can also be set by using the special value -1. Out of range values are corrected immediately when setting the sysctl parameter so no risk to cause any damage here anyway.


Why is HTTPS security allowed in most countries

In addition to @Petris's answer.

In addition, here are a few reasons why government security services don't object too loudly to HTTPS:

They need to use it themselves
The cost to the country of not using secure comms for commerce would be immense
It is often just as easy to attack an end point than it is intercept the comms elsewhere.

In some countries, points 1 & 2 may carry less weight. 1 because they can do what they like without having to worry too much about public opinion. 2 because they centrally control the economy.

As it happens, point 3 is interesting partly because it shows the level of insecurity in modern systems. But even beyond the technology, much of spycraft has always been about manipulating people.

Even so, you will see repeated attempts by the US government (there is one happening right now) to try and add "secure" back-doors to encryption products. There are still far too many - mainly politicians but some spy managers too - who believe that it is possible for technology to create something secure in general use but with a back door that only a limited set of authorised people can access. This is rubbish of course as has been demonstrated time and again. Even if it weren't, who is in control of "authorisation" - obviously that cannot work properly, especially when only 1 country with some seriously vested interests is in charge.

If you are interested in this topic, the website Techdirt often has interesting articles.

In regard to your specific questions:

If it is allowed among most government policies (USA, Europe, ...), then does that mean that it is weak enough for specialized attackers to decrypt the data ?

There is no such thing as perfect security. Well implemented HTTPS is pretty secure but it is hard to implement it properly and easy to get wrong. If attackers cannot get in, they will go round. Realistically, you can only make security too expensive and/or time-consuming to bother with breaking, if someone really wants in, they are likely to eventually do so.

Of course, if you can slow down an attacker long enough then the value to them generally goes away. But even that is not totally a given. The NSA and others have been gathering a lot of information for a long time. They are probably forced to eventually throw most away due to the cost of storage but information encrypted a few years ago that couldn't easily then be broken can most certainly be now if the desire is there.
How long would it take for an expert hacker to find the key ?

There are other sources for this information, it depends on the implementation but plenty of research is available that will show you how long it takes to break specific implementations.

Once again though, don't forget that going through a different route (e.g. malware or other hacks on the end points) may well be a lot quicker than trying to directly crack HTTPS.

You should also do a search on "HTTPS vulnerabilities" which will highlight the many and ever changing issues with HTTPS that, in many cases, mean that attackers don't need to brute-force their way into it.


I want to deploy from GitLab to AWS - so where exactly do I store my private key?

What you're facing here is the problem of secret management. It's kind of a big question mark in cloud architecture. The advice to never store secrets in version control is sound. It's just kind of hard to make that happen sometimes.

Some ways forward:

Gitlab has a notion of secrets. This is a way for the CI server to
maintain keys in a way where they're not in the repo but are
available to the deployment tasks. Cloud providers also support creating restricted keys which can do only one specified task. I recommend doing that instead of using root or admin credentials.
There is also a notion of release keys. Keys which are specialized to
a server and authorized only to pull new code for that project.
The major Cloud providers also offer secure secret management. It might
be worth deploying around a hosted secret management system.
Or deploy your own secure secret store something like Hashicorp Vault for very fine-grained control of secrets.


MITM: Is and How is it possible to manipulate HTTP POST data sent by the host to the server

Assuming there's no end-to-end security - such as TLS (the secure protocol that replaced SSL and underlies modern HTTPS) - then of course it's possible to modify the traffic. An HTTP POST request, like any other TCP message, is just a stream of bits traversing the various hosts that make up the [inter]net[work]. Each host receives the bits, checks where to send it to next, and retransmits it. If one of those hosts wants to, it can change the message before retransmitting it, or simply not send it along at all, or send it to the wrong destination, or...

Internet Protocol (IP), Transmission Control Protocol (TCP), and HyperText Transfer Protocol (HTTP) have no inherent security. They do not encrypt traffic, do not authenticate either the recipient or the sender, and do not protect the integrity of the message. There are security layers that can be used to provide some or all such protections, such as IPSec (typically used on enterprise local networks or for VPNs) or TLS (typically used for securing traffic over the Internet, and sometimes also within a local network; HTTPS is just HTTP over TLS). However, if such secure protocols are not used, are used incorrectly / with weak configuration, or are terminated before the message reaches its final destination (by a VPN server, or a reverse proxy or load balancer, for example), then an attacker can potentially tamper with the message en route.

Also, note that even when a secure protocol is in use, there's no way to stop an attacker with a MitM position from blocking the traffic. The attacker won't know what it says and won't be able to change the messages, but they can still simply choose to not forward along any particular stream of bits to the next host. The attacker can still tell where the message is from and where it's going (this needs to be in plain text so it can be routed correctly), and can tell its approximate size (for some protocols, can tell its exact size); these pieces of information may be sufficient for the attacker to know at least some of what's being sent. Also, an attacker may be able to convince the client to send attacker-chosen messages to the server. However, without some breach in either the server authentication or the message integrity check, the attacker still cannot modify a secure message itself.

EDIT: If you're looking for software recommendations, that's not really in scope for this site. However, any transparent HTTP proxy (a type of web server that is set up to forward messages to another server) can be used for this. Burp Suite can be configured this way if you want a hands-on view of the intercepted traffic, or an automatic one can easily be written in most programming languages (for example, the well-known HTTP MitM tool sslstrip is written in python using the python-twisted-web library).


What does a Remote Desktop Connection risk for both computers?

While "RDP"ing you have two very different and separates scenarios, it is very hard for a malware (crapware, virus, trojan...) to infect the RDP client (or server) machine, the only way is exploiting the RDP connection so it exploit the client through a malformed packet and manages to install in the new machine.

I have never seen that and I believe exploiting that is complex enough for most malware not to try to research into that scenario (very poor ROI).

As you have pointed out the most probable cause is the automatic sync between browsers.


How to check randomness of random number generators?

NIST has defined in NIST Special Publication 800-22 an extensive set of statistical tests for verifying a source of randomness.

However, while this is good enough to assert that a RNG is not obviously broken, it isn't sufficient to assert that a RNG is "good". It is the nature of RNGs that very subtle flaws can lead to breaking it. The only proper way of checking the robustness of an RNG is looking at the implementation.


Terminology (analogy?) for losing control of a secret due to re-sharing

It's called "the game of broken telephone", and was pulled on us in grade school. The teacher tells the left front pupil something, everone passes it on, and the right rear pupil says what they heard. It's hilarious!


Is this email from DigiCert about SSL certificates genuine?

The mail makes it clear that it is a reaction to a request to issue a certificate for your domain and that you need to verify that you are the owner of the domain by following the link if you want the certificate gets issued.

While the mail seems to tell a solid story it is impossible from the information you've provided to know if the mail is really from DigiCert and also if you should follow the instructions in the mail or not. The main information which is missing: Did you as the owner of the domain recently requested that a certificate should be issued for the domain or not? If you did not recently requested a requested a certificate to be issued then somebody might be trying to trick you into confirming something you did not want. If you instead actually requested the certificate and did not get it yet then this verification mail is probably valid.

If in doubt please contact the company you usually use to buy the certificates.


What does WEP access point show during aircrack-ng attack?

WEP cracking is a function if capturing a lot of traffic and brute forcing the mis-implementation of RC4 and initial vectors (http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy#Flaws). The only thing which may differ from "normal" traffic is the rate. If you are logging all of the authentications and handshakes, you would have to do some statistics on the timing of the events and compare them to a baseline. I do not believe the DD-WRT provide detail system logs of the actual packet traffic that might be useful to also look at.

If you are asking, how to detect a WEP attack on my network, the first response would be - WEP is easily attacked, so expect that if you must use WEP it will be compromised. Alternatively, you could look into Wireless Intrusion Prevention Systems, which could detect what it deems abnormal activity or matches patterns of suspicious activity.


Is it sufficient to convert ',  to avoid XSS in JavaScript strings?

Don't rely on using your own "conversion" rules, OWASP recommends using a security-focused encoding library to make sure the necessary rules are properly implemented:

Escape the following characters with HTML entity encoding to prevent switching into any execution context, such as script, style, or event handlers. In addition to the 5 characters significant in XML (&, <, >, ", '), the forward slash is included as it helps to end an HTML entity.
HTML entity encoding is okay for untrusted data that you put in the body of the HTML document, such as inside a <div> tag. However, it would not be sufficient in a number of cases, such as "nested contexts":
<script>...param used directly here...</script>
<!--...param used inside an HTML comment...-->
<div ...param used in an attribute name=test />
<param as a tag name href="/test" />
<style>...param used directly in CSS...</style>

In general, never use param inside any of these nested entities, even if HTML entity encoded.


can I trust Boxcryptor closed source software? Encryption of files for cloud hoster

That's a judgment call you'll have to make for yourself, but their technical overview has what I consider a huge red flag:

  Which data is stored on the Boxcryptor Key Server

    Private RSA key (encrypted with the user's password)

The fact that your private key is stored on their server, even if it's encrypted with your password, greatly weakens security.  It means that, at best, the security is as strong as your password, rather than being as strong as the underlying encryption.


If the user registers for my site via e.g. Facebook login, should I force the user to also create a password on my site?

The only reason I can think of for which this procedure can make sense is to prevent someone who has physical access to your computer/smartphone from logging in the site. Given that the Facebook session is usually opened for most users, anyone with access to the computer/smartphone of these users could get access to the site, impersonating them.

If you force the "attacker" to introduce a new password even after the Facebook login, you're eliminating this threat.

In any case, when physical access is gained, security is rather compromised.

(I would have liked to put this as a comment, but I have not enough reputation)


OpenSSH default/preferred ciphers, hash, etc for SSH2

The default algorithms (that is, the algorithms which the client and server prefer to use when given the choice) depend on the client and server implementations, how they were compiled and configured. So it may depend on the software vendor, software version, operating system distribution, and sysadmin choices.

On an Ubuntu 12.10, man ssh_config indicates that the default order for encryption is:

            aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
            aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
            aes256-cbc,arcfour

while the default order for MAC (integrity) is:

            hmac-md5,hmac-sha1,umac-64@openssh.com,
            hmac-ripemd160,hmac-sha1-96,hmac-md5-96,
            hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,
            hmac-sha2-512-96

The key exchange algorithm would follow this order of preference:

            ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
            diffie-hellman-group-exchange-sha256,
            diffie-hellman-group-exchange-sha1,
            diffie-hellman-group14-sha1,
            diffie-hellman-group1-sha1

Of course, preferences are subject to negotiation. An algorithm will be selected only if both the client and server support it (in particular, ECDH key exchange support is rather recent), and both client and server have their say in it (if they do not have the exact same preferences).

A survey is theoretically doable: connect to random IP address, and, if a SSH server responds, work out its preferred list of ciphers and MAC (by connecting multiple times, restricting the list of choices announced by the client). OpenSSH makes usage surveys but they are not as thorough (they just want the server "banner").


Database Error Error: SQLSTATE[23000]: Integrity constraint violation. Is it vulnerable to SQLi?

The error Database Error Error: SQLSTATE[23000]: Integrity constraint violation itself means that the column 's_id' could be a primary key and because of that, the system is not allowing it to be null. The details posted above cannot give a definitive answer whether the application is vulnerable to SQL injection or not.


MITM a TLSv1 connection - have one side use SSLv3

If the client supports only TLSv1 there is no way to force it to use SSLv3 instead. You also cannot tamper with the SSL handshake by replacing the protocols since the handshake itself is protected against tampering.

This leaves only the classical man in the middle attack where there are two SSL connections: one between client and MITM and the other between MITM and server. This attack fails if the client properly validates the certificate snce the MITM cannot provide a certificate which is both issued by a CA trusted by the client and also properly identifies the original server.


Why are extended validation certificates not used with email

According to the EV (SSL) Guidelines as of 1.6.5 (July 2017) from cabforum (warning: like others they've now 'optimized' their website to display as little data as possible, so to find anything useful you have to grovel through the pulldown) in clause 1:

  This version of the
  Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet
  and for code signing. Similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in
  future versions

Although FWIW the EV guidelines do not say anything about ExtendedKeyUsage, and in the baseline requirements (incorporated by reference) 7.1.2.3f says it MUST contain clientAuth and/or serverAuth and MAY contain emailProtection. So I think a member CA could issue an EV cert includig email without violating the rules. OTOH I doubt any email software currently checks for EV even when it supports X.509 (S/MIME) since this is not expected.

Of course there's the usual chicken-egg problem; legitimate email senders won't want to use this until at least a significant fraction of recipients are using email software or systems that support it, and at least most recipients won't even look for such support as long as no one is sending it. Possibly if some big players like gmail push this it might get some traction, in much the same way some browsers have been pushing improvements in web/HTTPS cryptography.


How does Single Sign On limit phishing risk

Newer forms of SSO, such as OAuth2, do not do anything more than provide a secure token for the client to use to verify if a user is actually authorized successfully. It does not leak their username, password, or anything else. It's simply an assertion that, according to the identity provider, it is a real user by whatever means they've proved themselves, and that they have some unique idenifier specific to that provider.

They could have used a smart card, fingerprints or other biometrics, etc, and that they have proved that who they say they are, but nothing more. Phishing attacks using these forms of SSO are pointless, because they get neither the credentials the user used, nor information about any other accounts they have. The tokens generated are only valid for a specific app, too, so they can't even use that token to access other services the user might have access to.


Reason for using Asymmetric encryption along with SHA256

The document your are reading uses the flawed analogy "encrypt with the private key". In asymmetric encryption, you encrypt with the public key, and you decrypt with the private key. "Encryption with the private key" is the way digital signatures were first described, because that kind of works like that in RSA. But the analogy does not work with other signature algorithms like DSA, and, when you look at the details, you see that it does not work with RSA either.

So just forget the word "encryption" here. They ask for a signature. A signature begins by hashing the data which is to be signed (with a hash function like SHA-256), and the rest of the computation involves only the hash output and the private key. The signature is not used in addition to SHA-256; SHA-256 is an element of the RSA signature process.

Why would they ask for a signature ? SSL already ensures data integrity. But they may want non-repudiation. When using SSL, client and server establish a tunnel for data; the client has some guarantee that it talks to the right server; if some authentication occurred (e.g. with a user name & password sent through the SSL tunnel), then the server also has some guarantee that it talks to the right client. The SSL mechanics also guarantee that the data is not eavesdropped on or altered while in transit.

What SSL does not do, however, is to produce proofs which could be shown to a third party (e.g. a judge). If there is some ulterior legal trouble between the client and the server, the server has nothing to show to a judge to demonstrate that the client sent a specific request. When the server receives the request, it is well convinced that it comes from the client, but the server cannot prove that it did not make a fake request to incriminate the client. To have such proofs, you need something else. That something else is partly technical, partly legal; the technical part is digital signatures (the legal half depends a lot on the jurisdiction, so there is no absolute answer here).

Summary: the other application wants a signature. SHA-256 is part of the signature process, not a redundant step. A signature is requested probably in order to achieve some sort of non-repudiation, which raw HTTPS does not provide (it might also be an overkill of an authentication system, though).


Does changing DNS help prevent MITM on ISP level?

In short: very likely just changing the DNS server will not help.

There are several technologies an ISP might use in order to redirect or MITM the traffic of a customer:

ISP provided DNS server returns a different IP address
This relies on the fact that most users will use the DNS server of the ISP. This is usually used for blacklisting specific sites and is a cheap option to do this. It does not work well for large-scale (all-domain) MITM since it somehow must return a different ISP-owned IP address for each domain or hope that their is a clear-text hostname in the TLS ClientHello (i.e. SNI).   A way around this is to use a custom DNS server.
ISP redirect any outgoing traffic to port 53 (DNS) to their own DNS server.
This is done so that the ISP's DNS server with the implemented blacklists is enforced even if the user has configured its own custom DNS server. This is a bit more expensive but still scales well. But it also has the same problems for large-scale MITM.It can be worked around by using DNS over HTTPS (DoH).
Deep Packet Inspection or transparent proxies.
Since the ISP is in the path of all traffic it can play active MITM on all traffic. But this is really expensive since it must check all traffic if this is TLS and then (and only then) intercept the rest of the connection. Easier would be to inspect only the common ports like 443  and accept that HTTPS on other ports will be missed.
This can be worked around by VPN, Tor or other tunnel technologies - as long the ISP still allows arbitrary traffic.
Mandatory proxy and deny most other traffic.In this case the customers must not only add the government CA but also explicitly configure a proxy. Any direct traffic which is not using the proxy gets blocked (i.e. Tor, VPN, tunnels...) , maybe with the exception of some protocols to send and receive mail etc. This is easier for the ISP than the last option and it guarantees a broader coverage, but not all applications can deal with proxies so that some applications might not work.

  if it won't help, what can I do to protect my privacy?

It depends on how the MITM is done and how it is enforced (both technically and legally). If you are lucky a VPN or Tor or some SSH tunnel or similar will work and use of these will also not cause legal trouble for you.

In general the workaround is to use something which gets not analyzed. Given that some applications outside the browser do SSL pinning (I think Dropbox on Windows) and that the government might want to allow these applications to work, they might have whitelists for domains which gets not intercepted. This can be used by custom tunnels which look like they have traffic for these domains but in reality connect to somewhere else. But note that with some advanced traffic analysis such misuse can be detected by the ISP and might be treated as unlawful.


The basic design you propose is secure. Of course, the security of any working system also depends on the implementation.

However, using public key crypto for backups has little benefit compared to symmetric crypto. The usual arrangement for backups is to have a symmetric key. You store this in two places: your working machine, and in a secure, safe, offline backup. There's no real risk around having the key on your working machine; it is only used to encrypt data that is already present on that machine.

Symmetrically encrypted backups are supported by a lot of software, e.g. Duplicati. This can even do incremental encrypted backups, which I think would be impossible with the public key approach you propose.


Is it possible to decode an encoded PEM SSL certificate without OpenSSL in CLI?

PEM files are base64 encoded binary data, this is a defined standard (so there's nothing to prove here). The reason for this encoding is spelled out in the intro of RFC 7468:

  A disadvantage of a binary data format is that it cannot be
  interchanged in textual transports, such as email or text documents.
  One advantage with text-based encodings is that they are easy to
  modify using common text editors; for example, a user may concatenate
  several certificates to form a certificate chain with copy-and-paste
  operations.

The header (and associated footer) is used to denote what the enclosed data is.

As for the binary encoding, this is the DER or BER encoding of ASN.1 data, again as mentioned in the RFC:

  Several security-related standards used on the Internet define ASN.1
  data formats that are normally encoded using the Basic Encoding Rules
  (BER) or Distinguished Encoding Rules (DER)

Because these encodings output binary data, you're unlikely so see much of interest when dumping it, save maybe a few strings.

To decode without openssl, you'll need another tool that can handle DER (or BER) decoding as well as ASN.1. There are libraries available for those in most languages and there are likely to be other command line tools out there. But since you'll need an external tool, might as well use openssl.

PS: friendlier description of PEM is available on wikipedia.


How does a client authenticate the domain controller

If there is a trust relationship already established Kerberos is used.

NTLM is used when

authenticating to a machine using an IP address
if the machine is in a different forest that is using NTLM
the target machine isn't in the domain
the machines are not on the domain
if firewalls block the kerberos traffic

Microsoft has information on their use of kerberos at http://technet.microsoft.com/en-us/library/bb742516.aspx.

You can also find more information at the following links:

http://en.wikipedia.org/wiki/NTLM
http://en.wikipedia.org/wiki/Kerberos_%28protocol%29
http://technet.microsoft.com/en-us/library/cc738300%28v=ws.10%29.aspx
http://technet.microsoft.com/en-us/library/bb742516.aspx
http://support.microsoft.com/kb/102716