A CRL is an object which contains the list of serial numbers of certificates which have been revoked by a given CA. It is a signed object; the CRL issuer is usually the CA itself (with the same key) but this power can be delegated.

An OCSP response is what an OCSP responder returns when it receives a request about the revocation status of a certificate. The request / response protocol is specified in RFC 2560. The responses themselves are signed by the responder and they can have an independent life; this means that a given OCSP response can be considered as a specialized CRL which talks about a single certificate.

During certificate validation, the verifier (e.g. a Web browser, when validating the server's certificate) must build a chain of certificate, from one of its trust anchor (aka root certificates), verify all the signatures and names and extensions, and then proceeds with ascertaining the revocation status of each certificate in the chain. This last step entails obtaining CRL and/or OCSP responses, validating them (which means verifying the signatures on them), and reading their contents. This raises two distinct types of question:

How does a verifier check that a CRL or OCSP response is genuine and up-to-date and really applies to the certificate at hand ?
How does a verifier obtain the CRL or OCSP response in the first place ?

CRL / OCSP match with a certificate

Let's concentrate on the following setup: the verifier wants to obtain the revocation status of certificate T (as "target"). He has already built and verified a chain of certificates which ends with CA certificate C followed by T, which means that the signature on T matches the public key in C. Also, the revocation status of C has been verified, and it is now T which the verifier is interested in. T can be an end-entity certificate (e.g. the SSL server's certificate) or another CA certificate as part of a longer chain, which extends beyond T.

A CRL is signed; who signs it is a matter of a subtle distinction between X.509 and its PKIX interpretation in the context of the Internet. For the "original" X.509, a CRL is valid if it is signed by an entity who has a valid certificate and bears the same Distinguished Name as the CA. This works well if the CRL is signed by the same public key than T, i.e. the key of the CA C: at that point, C is a fully validated certificate so its public key can be "trusted" (the verifier is reasonably sure that the public key is really owned by an entity which goes under the name given in C's subjectDN field). However, it could be any other certificate with that name, and located at the end of a valid chain of its own (which may imply more path building, validation and processing of CRL). In X.509, distinguished names are everything, because X.509 was meant for the Directory, the worldwide LDAP-like server aggregate where everything is uniquely referenced by it distinguished name.

PKIX, the working group which deals with the Internet, has noticed that the Directory, marvelous as it may be, shares some characteristics with mythical beasts like the Mokèlé-mbèmbé, specifically that it does not appear to exist at all (at least, no confirmed sighting has been reported). Correspondingly, PKIX enforces a restriction to keep trouble contained: the certificate of the CRL issuer must be at the end of a path which begins with the same trust anchor as the path which ends with T. This should avoid trans-root issues when two distinct CA which do not know each other ended up using the same distinguished names (they could have noticed the issue right away if they had worked in the context of the Directory, if it had existed). This specific point is in RFC 5280, section 6.3.3, step (f).

The role of CRL issuer can be delegated, in which case the distinguished name of the CRL issuer is found in the CRL Distribution Points extension in T itself, and a matching Issuing Distribution Point extension is found in the CRL.

For OCSP responses, a similar system is used. The OCSP response may be signed by the CA itself (with the key in C); or there may be a dedicated issuer. Things are more constrained there: when there is a dedicated issuer, it must have a certificate which is directly issued by C itself, and bearing a specific extension which marks it as an OCSP responder (Extended Key Usage with the id-kp-OCSPSigning OID, see section 4.2.2.2 of RFC 2560). The certificate for that responder can be attached to the OCSP response itself (outside of the signed area, but encoded within the same blob nonetheless).

The important point is that it does not matter how the CRL or OCSP response were obtained: they are signed object, verifying the signatures and all the name matching and extension contents is sufficient. The object themselves can travel over TCP connections, emails, USB keys, caravans of camels, learned by heart and declaimed by a Shakespearian actor, whatever. The signature abstracts these details away. Certificates, CRL, OCSP responses cannot be "manipulated" without invalidating the signature.

CRL and OCSP responses have validity dates. They both have a thisUpdate field which tells when they were issued (formally, the date at which the information they contain was gathered). They also have a nextUpdate field which is the date before which a newer version should be issued; thus, it serves as a kind of expiry date. It is expected that verifiers cache CRL and OCSP responses, using these dates to know whether the cached version is still usable, or a new one should be obtained.

How to locate CRL and OCSP responses

The way a CRL or OCSP response is distributed is not important for security, but, of course, a verifier cannot guess URL out of thin air. The URL at which CRL can be downloaded is encoded in the CRL Distribution Points extension of the certificate T (this extension has two roles: a validating role for delegation of CRL issuance power, and a descriptive role to give pointers to locations where the actual CRL could be downloaded). http:// URL are common, but also ldap:// URL (especially in closed environment like enterprise networks). An https:// URL for CRL download can lead to a loop (since the download entails validating the certificate of another SSL server) hence it will tend not to be supported well, or at all (Windows will not follow such URL).

Similarly, the URL at which an OCSP responder can be found is in the Authority Information Access extension in certificate T.

These URL are indicative only; the verifier can use any CRL or OCSP response it could obtain, regardless of its provenance, provided that all the signatures are verified. Since CRL and OCSP responses have a non-negligible lifetime, it makes sense to cache and reuse them. OCSP stapling is a way for a SSL server to obtain OCSP responses for his own certificate, and provide them to the client, under the assumption that the client may need them. This makes the whole process more efficient: the client does not have to open extra connections to get the OCSP responses itself, and the same OCSP response can be sent by the server to all clients within a given time frame. One way to see it is that the SSL server acts as a Web proxy for the purpose of downloading OCSP responses.

OCSP stapling is entirely up to the SSL server; the contents of the certificates and OCSP responses is unaffected. The CA or the OCSP responder need not be aware that stapling occurs at all.

"Removing" the OCSP stapling flag from the handshake would break the Finished messages at the end of the handshake, so this is not feasible for the attacker, unless this would allow him to break the whole handshake before the end. However, it does not: the lack of OCSP stapling does not mean that the client will not ascertain revocation status; it just means that the client will be on his own, and will have to obtain the CRL or OCSP responses by itself.

The unfortunate thing about OCSP stapling is that it is not yet widely supported. The idea is sound, though. Its security implications is that, with stapling, a SSL server has a powerful argument to convince the Web browser to actually do its job and not skip revocation status checks altogether, like many Web browsers are unfortunately prone to do (things change in that matter, but slowly).

Note: CRL / OCSP response lifetime usually ranges from a few minutes to a few days. The dates are verified with regards to the client notion of time; clients with out-of-date clocks can run into trouble.


Shared Office Network Security - VPNs, Firewalls, and systems

Network attacks where the attacker connects to your wireless network are uncommon.  That doesn't mean they can't happen, just that it shouldn't be the first thing you worry about.

You are better off making sure all your PC software is up to date -- that includes your applications too (don't forget Adobe, Flash, Java, etc).

Host based firewalls are fine.  The biggest risk is that yo are going to download some sort of malware.  Unfortunately, most antivirus software does a poor job of detecting it.

Consider using a service like OpenDNS that will help you stay away from malicious sites.


Based on the timestamps (1min 46sec & ~15min gaps between events), this is not a DDoS.  This is about par for random DoS attempts against an exposed device on the Internet, such as your Netgear router.

A DDoS would show many events flooding in at the same time... you would get lots of logged events per second, or at the very least hundreds per minute.


Strong password vs. restriction on number of attempts

Why do internet services not go the same way?

Fundamentally, because users don't want it.

Implementing stronger security measures would mean spending money to do it, and for most internet services, stronger measures would also negatively impact the user base and usage of the service. Especially if you're an ad-revenue driven internet service (as most are), the last thing you want to do is prevent people from using your service for a period of time, because that's lost revenue.

Balancing security and convenience is difficult at the best of times, and when it comes to internet-based services, it is exceptionally difficult, because typical users, and the vast majority of users, are simply not willing to sacrifice any convenience at all, no matter how much security they get in exchange.  As you note, typical password complexity schemes allow for passwords like Password1.  Typical users pick a single, simple password like that, and use it for everything. (As every big password dump, ever, verifies.) They don't like to be told they can't use their password because it's laughably weak.

They just want to use the service, and are not willing to suffer much inconvenience to do so. With very few exceptions, if your service doesn't let them, there are a lot of nearly identical competing services that will, and that's where they'll go instead. And if they're not willing to "put up with" using anything remotely resembling a decent password, they certainly aren't going tolerate being locked out of their service or having an actual strong password/phrase forced on them.

To that point, here is a decent estimation and analysis of usage for Gmail's two-factor authentication option, which links a research paper from EuroSec 2015 (pdf) reaching very similar estimates. A free, optional, very secure (and easy, convenient) way to protect your Gmail account from being hijacked... and about 6.5% of people can be bothered to use it.

So, if Google can only manage to get about 6.5% of people to use a free, convenient layer of security for their online service, no one stands a chance of imposing stronger security measures on their users.


Are there security issues in not supporting TOTP 2FA for 1Password?

So to start with, your question is based on a false premise, namely that you can protect your 1Password account using 2FA (Two-factor Authentication) from the 1Password website.

You can use any TOTP compliant app or a Yubikey device.

1Password can itself be used to generate TOTP codes but it ABSOLUTELY SHOULD NOT be used to generate TOTP codes for itself (for reasons which should be obvious!)

Enabling 2FA with 1Password requires a 1Password membership.

Source: https://support.1password.com/two-factor-authentication/


WHY redirecting HTTP version of a site to HTTPS version is dangerous?

First, to answer your question:

It's not that redirecting HTTP to HTTPS is more dangerous than NOT redirecting to HTTPS. Redirecting HTTP to HTTPS is in fact extremely important!

The thing is, if somebody is hitting a security-sensitive site over HTTP, something is already wrong. The user should be using HTTPS from the beginning. Of course, web browsers are unhelpful here - they default to HTTP unless the user specifically types the https:// part before the domain name - but that's legacy behavior that we basically just have to deal with.

The solution to this problem is something called HTTP Strict Transport Security (HSTS). HSTS is a way for a website to tell a browser "hey, this is a secure site, don't you ever try connecting to me over insecure HTTP, OK?". All modern browsers (including IE11, though not older versions of IE) support HSTS, meaning they will only use HTTPS for that site (even if the user typed http:// instead; the browser changes it to https:// before sending the request).

HSTS does have one weakness: for the server to tell the browser to never use HTTP, the browser has to already have connected to the server. The first such connection is the most likely one to made over HTTP rather than HTTPS anyhow (because the user just typed the domain name into the URL bar), so an attacker almost always has at least one shot to hijack the connection (more on that in a sec). Not good. The solution to that is to use HSTS Preloading, which is a list built into all HSTS-supporting browsers of sites that the owner has specifically requested to never be visited over HTTP; the browsers are pre-configured to have HSTS already enforced for those sites.

It is worth noting that, for inclusion in the HSTS preload list, your site MUST redirect any HTTP request to HTTPS. That must be the first thing it does, in fact, before doing any other redirect or serving any content.

The answer to "how is that possible?" is a clever attack called "SSL stripping" (see previous Q on Security.StackExchange). In a nutshell, when the browser connects to a site over HTTP, it has no way of knowing whether it is actually talking to the server it meant to reach, or some attacker who has redirected or intercepted the request. That attacker (if present) could then make an HTTPS connection to the real site, sending along the same request it got from the user (just over the secure connection this time), and then decrypt the HTTPS response and send it back to the user via plain-text. In the process, the attacker can record and also modify the responses (and the requests), doing things like changing any HTTPS link into an HTTP link, so that the user doesn't click some link or button and switch to a secure connection (which the attacker could not intercept). If the user doesn't notice that they're on HTTP instead of HTTPS - which they can only do by looking at the URL bar closely; the site looks otherwise identical - the user might do something like log into the site, which would let the attacker see the user's credentials. An attacker who is doing this is termed a "Man In The Middle" or MITM.


Why do file storage sites have a long unique id for their download links?

Is there any (security) reason behind for having it that way?

Yes - a type of Security through obscurity - the files aren't really secure as the URLs are available without authentication, but it would make them reasonably private as they are not guessable. You would need more information (such as browser history logs) or some kind of brute force that would be unfeasible in this case.

  I was thinking maybe they do it like that so that people can't just increment the id by 1 and just download everything they come across which would result in unnecessarily losing of more bandwidth. But that is not the case, because both the ID and FILE NAME need to match, and file names aren't easily guessable.

Aren't they? How about readme.txt, password.txt, untitled.bmp, CV.doc, etc.

Common word lists are widely available, and can be fed into a brute force program in combination with common file extensions and different IDs in order to execute an attack on your system. This is why it is a good idea to have a secure random component in your URLs.


How do server know the CSR sender is approved client?

I guess you want to enroll users by POSTing CSRs. There is already enrollment schemes builtin browsers so you dont have to POST CSR's. Those enrollment schemes will also automatically install the client certificate in the browser store, so Everything is done in one shot.

Here you have Everything to get started:
https://stackoverflow.com/questions/9197484/generating-client-side-certificates-in-browser-and-signing-on-server/9198400

This should take care of Everything. Now, your only problem is authenticating users as users Before enrolling them.

I guess this is the problem you want to solve, in other Words, authenticating users so not anyone can enroll themselves, eg only specific invited indivuals should get a account.

If you can provision software to the client computers via some administration suite, you could provision a "RunOnce" that contains a url like http://www.example.com/CSREnroll.cgi?key=sgdghdghdkgkdsgfketgebgkebekgbksdhfbkgbavbkajvbebkjgbtkekagb where key= is a securely generated, random one-time key, that allows enrollment of one certificate. Since your provision software will propably be able to know the client's IP, you could also lock the key= to only be valid to the IP in question, thus gaining extra security so if this one-time key would leak out prior to its usage, it would be impossible to use it.

If you dont have any administration suite and no possibility to identify users today, I would suggest manual enrollment. This can be done by setting up a password protected enroll page that only you as a administrator know the password of, and then you physically visit each user and enroll them.

Installing a one-time certificate is a unneccessary step, since you would still have to verify the users prior to installing the one-time certificate. And if you have verified the users as authorized, then you dont need to take the step of installing a one-time certificate.

If the users are located not so near, you need to establish Another way to verify the users. Lets say the users need to call the "Helpdesk" to get a account, and verify themselves with a customer representative. Then you could make a page where they have to enter a 8 digit "enrollment ID" that you give to them over the phone after successful verify. This enrollment ID could have a validity of about 5 minutes giving maximal security.
You could even have a challenge that they have to read to you, you enter all details that should be written in certificate, they get a response, and they have to type the response to get their cert enrolled.


(I feel sure I've answered essentially this question before, but I can't find a dupe.)

OpenSSL partly created, and supports, two (or four depending how you count) types of PEM formats for private keys.

Your first file, with BEGIN EC PRIVATE KEY (and no Proc-type,DEK-Info inside), is the 'traditional' or 'legacy' format which is specific to one algorithm, EC. It contains the private key in the format defined by SEC1 from SECG and also available as rfc5915, then encoded/wrapped as 'PEM' i.e. base64 with linebreaks and header/trailer lines.

Your second file, with BEGIN PRIVATE KEY, is the 'new' (since about 2000!) PKCS8 format which is generic and covers all algorithms. Actual PKCS8 was first published by RSA Labs and has become harder to find since RSA was acquired by EMC and that by Dell but is also available as rfc5208, again encoded/wrapped in PEM. This format (but not the legacy format) is among several PEM formats which are updated and restandardized in rfc7468 (see section 10, even though the TOC doesn't hyperlink it correctly!)

Although formatted differently, they do contain the same key:

$ cat se218335.a; openssl pkey -in se218335.a -noout -text
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBaYCj/CjZjq9aYehcvyejxqx5WVJ3OnfNbBq2+7iKyJoAoGCCqGSM49
AwEHoUQDQgAE1Rcx8Zo84aqSWqT/7i5NN7p+PI6dRfGdFFJapfcBlMhMjFsJkrxh
vncLphHuZHBoEILRMKf7hfVJ+tMwHMxQMA==
-----END EC PRIVATE KEY-----
Private-Key: (256 bit)
priv:
    16:98:0a:3f:c2:8d:98:ea:f5:a6:1e:85:cb:f2:7a:
    3c:6a:c7:95:95:27:73:a7:7c:d6:c1:ab:6f:bb:88:
    ac:89
pub:
    04:d5:17:31:f1:9a:3c:e1:aa:92:5a:a4:ff:ee:2e:
    4d:37:ba:7e:3c:8e:9d:45:f1:9d:14:52:5a:a5:f7:
    01:94:c8:4c:8c:5b:09:92:bc:61:be:77:0b:a6:11:
    ee:64:70:68:10:82:d1:30:a7:fb:85:f5:49:fa:d3:
    30:1c:cc:50:30
ASN1 OID: prime256v1

$ cat se218335.b; openssl pkey -in se218335.b -noout -text
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgFpgKP8KNmOr1ph6F
y/J6PGrHlZUnc6d81sGrb7uIrImhRANCAATVFzHxmjzhqpJapP/uLk03un48jp1F
8Z0UUlql9wGUyEyMWwmSvGG+dwumEe5kcGgQgtEwp/uF9Un60zAczFAw
-----END PRIVATE KEY-----
Private-Key: (256 bit)
priv:
    16:98:0a:3f:c2:8d:98:ea:f5:a6:1e:85:cb:f2:7a:
    3c:6a:c7:95:95:27:73:a7:7c:d6:c1:ab:6f:bb:88:
    ac:89
pub:
    04:d5:17:31:f1:9a:3c:e1:aa:92:5a:a4:ff:ee:2e:
    4d:37:ba:7e:3c:8e:9d:45:f1:9d:14:52:5a:a5:f7:
    01:94:c8:4c:8c:5b:09:92:bc:61:be:77:0b:a6:11:
    ee:64:70:68:10:82:d1:30:a7:fb:85:f5:49:fa:d3:
    30:1c:cc:50:30
ASN1 OID: prime256v1

OpenSSH began using the OpenSSL legacy formats (RSA and DSA as well as EC) decades ago, and ssh-keygen has never been upgraded to write PKCS8, although it as well as the ssh and sshd (and ssh-add) programs can read PKCS8, because they actually call OpenSSL library routines that handle both types. In particular after extracting the pubkey and configuring it, I can use either of your files to authenticate just fine:

$ ssh -i se218335.a localhost echo hi
hi
$ ssh -i se218335.b localhost echo hi
hi

If you are having a problem using the second file and want to solve it, you might ask about that.


What's the benefit of using a specific implementation framework vs using the generic steps presented in most developed security frameworks?

You're familiar, I hope, with the first rule of Information Security club; don't roll your own crypto. Turns out that this rule has wider implications; you really shouldn't roll your own security frameworks either.

A well established framework has had a lot of smart people looking at it for gaps, and on a more practical level it's been deployed in the real world a lot and has brought benefits. (I don't actually think SKIP is a well established framework, but that's not really the point to your question.)

Also, it's not a criticism of a framework that it is reminiscent of other frameworks - good security practice is good security practice. SKIP seems to be an attempt to apply a PDCA process to vendor supplied equipment; naturally it's going to look a lot like other frameworks based on PDCA.

In addition, using a standard framework makes it much easier (and hence cheaper) to do external audits, because you can hire an auditor who already knows the framework.


For a non-technical solution: How about taking a picture of the four of them in the same room together, possibly holding a newspaper to give a "no-earlier-than" date, and maybe a printout of the document, and add the picture to the document to be signed?

I'm fairly confident that this would convince most people that the four people in the picture came together in order to sign the document in question, especially if the signature service gave the same date for when the signatures were made as the date visible on the newspaper in the picture.

This is assuming that you can't have a trusted person present that can simply vouch for the four people all being there with his own signature on the document.

If it's just that you must each witness that the others have signed, you might do it like this:

A signs the document.

B signs A's signature.

C signs B's signature.

D signs C's signature.

A signs D's signature.

B signs A's 2nd signature.

C signs B's 2nd signature.

(You need B and C to sign again to prove that they know about D's signature, too. If you stop after A signs D's signature, you have no way to know whether B and C know that D signed).

I also have an idea that uses zero-knowledge proofs, but this is so convoluted that I don't think it would interest you.


What is the security risks of increasing the maximum number of HTTP parameter?

As someone said in a comment, this reeks of bad design.

Anyway, in the past there have been denial of service attacks against server software done by using many parameters that share the same hash as used by the hashing function in the server to convert the parameter list to a dictionary/hashmap. These hash collisions would lead to a wildly increased load in bad server software (that was, most prominent example of that category, the PHP interpreter).

That problem can be mitigated by using an unknown salt for that hash function, so that the attacker can't predict which parameters would lead to a hash collision.

With that many parameters, however, chances are that you generate hash collisions if you just pick random parameter names.

Anyway, the assumption that someone would still be able to DOS a server with that is purely hypothetic.


Exchange 2013 blocks txt file attachments - are there security reasons?

I've been supporting and administering email for 18 years, and never had a valid reason to block text attachments.   Here are some issues that I can think of, that aren't exclusive to TXT attachments alone, but rather regard attachments in general
Unicode parsing
The only two issues I've come across is this unicode bug but it's theoretically possible that other applications that have issues parsing and/or displaying unicode.
MIME-type vs file extension
Attachments in SMTP include not only a file extension .txt but also a MIME-Type and a corresponding encoding (as mentioned above).  Should any of these "metadata" not match up (vbscript with a mime of Text, or vice versa) it's possible to get unexpected results from a client.
Issues may include

File attachment icons appearing like a TXT file in the client, but are really an EXE
Clients (or services) improperly handling the attachment, potentially executing it
A variation of the above that causes the client (outlook / thunderbird, etc) to download an image, or verify a DKIM signature, losing the anonymity of the client.

Outlook
Since the most common client in an Exchange 2013 environment is Outlook, I'll focus on that, even though most of the issues here have been thoroughly looked at and is no longer an issue (as long as you're on a current and patched build).
Outlook Preview Pane Risk
The Outlook preview pane uses a special, locked down version of IE. Given that IE could execute "text" data as if it were HTML/XSS or any other active content, this could pose as a security risk.  (Outlook vulnerabilities as the preview pane has happened in the past)
WebReady Exchange Server Risk
A similar attachment to HTML parser is installed on the Exchange server itself called WebReady, and it converts attachments into HTML for Outlook Web Access clients.  This has already been an issue in the past, causing vulnerabilities and executable code to run in the context of the Exchange Server itself.  Read more about this security feature here.
Summary
In my opinion, before your admin blocks TXT attachments they should consider disabling Webready and address the lower hanging fruit first:

Improved authentication for end users (smartcard etc)
AV/AS on the server, and gateway
SMTP security including DMARC, DKIM, SPF, and Opportunistic / Secure TLS where possible
Content scanning
On demand portal encryption, SMIME or PGP encryption

If they are disabling attachments as a form of information management, to prevent the disclosure (or liability of receiving ) data, then they should consider alternate controls.
If they are disabling TXT attachments for security / encryption reasons and want all data encrypted, know that some encryption software sends the encrypted payload or public to the clients using TXT data.  Conversely, banning this activity is easy since there is a string in the file that can be scanned for.
Just for clarification, by "blocking" do you mean classifying it as a Level 1 or Level 2 attachment in Outlook?


Is using JSON really enough to fix PHP object insertion?

Unlike unserialize, if you execute json_decode alone it will not be able to instantiate any different variable types besides simple ones (e.g. arrays, string, int, float, etc), so it is fairly safe to run it with user input data.

The problem in your code is with the e function. If the parameters you pass to it come from an untrusted source such as user input, some attacker could just pass the name of a potentially dangerous function that exists in your code, so e would execute it and it could harm your application. You should never let this happen.


How to secure containerized python source code deployed at client side cloud

Accept that you can't do it...
If you deploy a container (that needs to be accessible and re-bootable by the client, 101 times out of 100) then the container's contents is at the complete mercy of whatever containerization technology will have been adopted.
Either you can trust your client, or you cannot. If you cannot, then nothing stops them from cloning the container and either access its storage (if unencrypted; but if you encrypt it, you'll have to be available at each reboot) or pin the container memory and read the source off it. Almost always, the latter approach is available even without cloning, and containerization technology means that the application is not aware of what is happening, and has no way of detecting or stopping it.
All protection schemes in these cases rely on something that the client has not access to. You need to ask, "is there something - before I give them the container - that the client has not access to?". If the answer is "No", then you can stop right there (if it is "Yes", then you need to ask, "and do I have access to that?"). Hardware keys, for example, is something the client hasn't access to. External keyservers are also something they don't have access to. Third-party PAAS services also. Android "secure space", to a large extent. So, what you ask can be done in principle, but very probably, not in your scenario.
...and move on.
Now, unless you're doing "jobsecurity through obscurity", there's an overwhelming chance that your code will be something complex, probably difficult to maintain for somebody unfamiliar with it, and will contain nothing embarrassing or unprofessional.
So, your target becomes simply to be cheaper than just stealing your work. This can be done in several ways, starting from making it clear than stealing from you now will mean not simply renouncing to the next few fixes (which someone might be willing to accept), but to any and all maintenance. This you can do by calculating e.g. the hashes of your code units, and verifying them to ensure they haven't been tampered with -- in which case you will charge for the restoration or for your reverse engineering any changes.


Secure database password stored in an env variable

Assuming you run the web server as its own user, then only root and that user can read your OS Environment Variable†. Unless you're using 30 year old AIX or something. Even Windows protects envvars.

If you encrypt the values, how are you going to secure the key‡? The key could be read by the user or root too.

If you store the values in a file, how is that safer than an envvar? It isn't. An envvar is safer in that you won't accidentally put the passwords in source control.

† This does not apply to command line options!
‡ You're going to buy an HSM, that's how. The HSM can still be used by root or user


Page 239 in that PDF has a Turbopascal program of Safer, including the key schedule. So I would start there (the author himself says

  Appendix B contains a TURBO PASCAL program that implements encryption for the full r-round SAFER K-128 cipher. This program should be taken as the official definition of the SAFER K-128 encryption algorithm.

on page 214....)


Do I have to comply with PCI DSS for bank transfers?

PCI DSS is for handling card data

Payment Card Industry Data Security Standard is, as the name states, a standard for handling payment card data. Compliance with PCI DSS is generally a contractual requirement, as a condition in your agreement for accepting credit card payments - if you don't have such an agreement, you're not required to comply.

The confidentiality of account numbers depends on your location. For example, it is rather common EU practice to display your IBAN account number to anyone interested (e.g. in the Contacts section of your webpage) but as far as I understand in USA that might expose your to certain types of fraud, so you might want to hand out that number only to actual customers that need to pay.


Basic TLS questions: Implementing a specific TLS version and cipher

The TLS version is a property of the connection

Correct. The certificate has nothing to do with the TLS protocol version.

  The recommendation to support many different ciphers only applies if I'm implementing a TLS client. In my case, the browser is the client – so, when I generate my cert, I just need to choose a single cipher which (a) is on the approved list, and (b) is supported by all major browsers.

Mostly wrong.
The server should support at least some of the (secure enough) ciphers the client supports. Since different clients might support different ciphers the server should better support a sane and secure set of ciphers to support a variety of clients instead of only a single cipher. See recommendations from Mozilla.

Also, the cipher has mostly nothing to do with the certificate. While ciphers with RSA authentication can only be used with RSA certificates and ciphers with ECDSA authentication only with ECDSA (ECC) certificates one cannot choose a specific cipher when creating a certificate. In other words: a certificate can used with lots of different ciphers. It is only necessary that the kind of public key in the certificate (RSA or ECC) matches the kind of authentication in the cipher (RSA or ECDSA).


Wise/Safe to use Firejail within a SELinux preconfigured O/S?

To be clear, this question is more of an opinion than a hard fact.
SELinux and Firejail perform sandboxing by separate means. At its core, SELinux is an advanced access control list (using Labels), while Firejail uses Seccomp and Linux Namespaces (https://firejail.wordpress.com/).
Yes, installing setuid program does always have a danger, and since you already have SELinux, it may not provide more benefit. Though not all programs have their own SELinux profile, and fireJail could offer more options in this case.
In security, there is a concept of belt and suspenders approach to add extra protection where possible. Your home had a lock on the doors and windows, do you still use an alarm?
SELinux is relatively hard to configure, compared to fireJail. Though FireJail is not an always-on option like SELinux.
$ firejail firefox                       # starting Mozilla Firefox
$ firejail transmission-gtk              # starting Transmission BitTorrent
$ firejail vlc                           # starting VideoLAN Client
$ sudo firejail /etc/init.d/nginx start  # starting nginx web server

If I have to choose one, I would definitely choose SELINUX as it is built into the Distro and comes preconfigured.
If you are very concerned about the suid, you may want to consider mbox (https://pdos.csail.mit.edu/archive/mbox/) though I cannot speak to its quality or if it is maintained.
Update
Reviewing the text above and as my usage of fireJail has increased. There are definitely advantages to using fireJail. AppArmor and SELinux are more concerned about protecting systems from applications. Many Application profiles will not provide as much isolation for the user.
On Normal firefox, it can see most of the user's home directory.
Under FireJail profile, that is more limited to Download, firefox, and .cache, and so on.
Additionally, Mbox does not seem updated in a number of years.  It likely should not be used.


Can a malicious WIFI network force a connection

Yes, under certain conditions.

If you have previously connected to a "hidden" wireless network, your NIC may continuously broadcast their BSSID's in hopes of connecting to them. It's the only way to "automatically" connect to a hidden network, because there is otherwise no way for the card to know when it is in range to a known hidden network.

This looks like this:

Hello, 'Home Network'? Are you there?
Hello, 'Office W-Lan'? Are you there?
Hello, 'Home Network'? Are you there?
Hello, 'Office W-Lan'? Are you there
...

An attacker can listen to these probes and reply with "Hello, here is this 'Home Network' you are looking for." If the network was unsecured, or you have an OS that doesn't mind quietly deprecating security, you will then automatically connect to a malicious network.

This of course has a lot of "if" conditions, so if this is a real problem for you in practice is not sure.


Does a flatbed scanner remember any of its previous scans?

Basically, no, flatbed scanners don't remember old scans.

A flatbed scanner sees a lot of incoming data (the pixels) and outputs them all on whatever communication medium it has (say, USB). RAM is used as a buffer between the two. Cheap scanners don't have a lot of RAM, much less than enough to contain one scan, and rely on the host computer to be able to read the data fast enough (or to stall the scanning in case of overflow, although this would be likely to induce picture distortion).

Network scanner usually have more RAM, because they may need to contend with network congestion, so they must be able to buffer one full picture. Some may buffer several pictures, in particular automatic scanners coupled with a printer (so that you may efficiently copy a bunch of sheets). None of them, though, has any business storing files permanently so it would make little sense for them to use anything else than RAM. Correspondingly, after a few minutes without power, the data is gone for good.

Some advanced scanners who act as file servers (so that network machine may obtain scan results afterwards) could store data permanently, and require special procedures. I really doubt your scanner would be of that kind, though. It would not be reasonable in terms of economics.


Your payment gateway should be able to provide you with a tokenized system for recurring payments where you submit the cc to the payment gateway once and they return an authorization code which you will use instead of a cc number for the recurring payments.

This is a far better solution than storing credit card numbers in any shape or form. Please contact your payment provider for advice before you consider copy/pasting encryption advice from the internets.


Whats the actual harm in open directory listing? What can a attacker do here?

Because it makes sense to do it when it makes sense to do it. The usual practice is to disable it and only enable it for directories you specifically want it to in order to avoid accidental information disclosure but of course... not having a directory listing doesn't prevent them from accessing your /admin/err.log or whatever because you can still guess file paths. You might for example have a directory where you store pictures of your employees with random file names to avoid people from scrapping your website (but still allow them to access single pictures when necessary). If you don't disable directory listing (and have no index.html usually) an attacker could easily get a list of all employees that way.


CSRF attack on file upload functionality

Yes, you are vulnerable. Every endpoint that modifies the state of your server needs to have protection against CSRF attacks. File uploads are not excluded.

So how can this be exploited? If your site is example.com the attacker host some JS like this on a site that she tricks the victim into visiting:

myFormData = new FormData();
myFormData.append("file", fileContent, "filename.txt");
fetch("http://example.com/fileupload.php", {
    method: "post",
    body: myFormData,
    credentials: "include"
});

This will make the victims browser send a POST request to your site, with whatever the attacker chooses as fileContent as the file.


Yes, there are some examples of malicious CSV files causing random "code" execution. People choose to open CSV files in MS Excel or Open Office or such software which have macro execution capabilities.

Some examples:

https://www.contextis.com//resources/blog/comma-separated-vulnerabilities/
https://hackerone.com/reports/72785

If your environment does not use popular applications such as MS Excel to open CSVs, the risk is significantly reduced. I would also look for the presence of external, potentially malicious links in the downloaded CSV that might be hosting drive-by downloads (hence you would want to avoid visiting these links).


Can non-torrent-supporting browsers run torrent clients like jstorrent.com for Chrome?

You are wrong as far as assuming how jstorrent.com works. So I will elaborate a little on that first.

With jstorrent.com you are required to install it as a Chrome extension. Yes, it is only written in JavaScript. But as an extension it is no longer restricted to the sandbox environment it is in. It now has access to powerful APIs that allow it to access your filesystem and more. It also doesn't have the limitations that you would have with storage sizes and more. Additionally Chrome doesn't have a built in torrent client. These are implemented in the extensions. And jstorrent.com cannot possibly run at all as a regular website as a non extension.

JavaScript itself minus a few exploits in the past it is by far the safest browser scripting language available. Browsers intentionally try to lock it down and sandboxed as possible. Where things like ActiveX, Java applets, and Flash APIs are not completely sandboxed and a browser has limited control of them. But you can bypass this JS sandbox such as using a Chrome extension or using an application built with Electron which intentionally removes restrictions to allow expanded application development not possible through a regular web browser experience.

So could another browser support a JS torrent client? If they have an extension system or allow mods to bypass sandbox restrictions then absolutely. Firefox has a torrent client extension as well.

However both have separate APIs and separate ways of doing things. You would be looking at a lot of work to get jstorrent.com on Firefox or another browser.

So in closing, Chrome is not doing anything out of the box to risk your security. You are as soon as you are opting in to install an extension with elevated privileges. And yes, a torrent client could be made in the same way for any browser that has an extension system with the desired APIs available.

Edit: It is worth mentioning there are a few solutions out there where an application runs on your machine and acts as the client. Using web sockets they can transmit that data to a torrent client front end coded only in JavaScript and no extensions required. However, it is important to know the sandbox at this point is bypassed with the installed agent and not the web browser.


This might not be exactly the same as what was in the first Netscape release with SSL, but you can find one early list by running an emulated Windows 95 system from a 1996 install disk at win95.ajf.me and look at the built-in site certificates (Control Panel - Internet Properties - Security tab):

AT&T Certificate Services
AT&T Directory Services
AT&T Prototype Research CA
internetMCI Mall
Keywitness Canada Inc.
Verisign Class 2 Public Primary CA
Verisign Class 3 Public Primary CA
Verisign Class 4 Public Primary CA
Verisign/RSA Commerical
Verisign/RSA Secure Server

A later source from January 1999 is this thread, where Dan Geer compiled a list of the certificates included with Netscape v4.5 and Explorer v4.0.

Another good resource on early CAs is a project to create a "top-level certification authority (CA) using paper and ink," The Global Trust Register, which has a list of global CAs that the authors could find and verify in 1998. There is a copy available online here.


It is not the bits themselves that are insecure, but if an attacker was able to exploit a flaw in a setuid/setgid binary it would result in code execution under elevated privileges. So by reducing the number or binaries (and lines of code) that run with elevated privileges you are reducing the attack surface.


How does process migration work in Meterpreter

This is how migrate works in meterpreter:

Get the PID the user wants to migrate into. This is the target
process.
Check the architecture of the target process whether it is 32 bit or 64 bit. It is important for memory alignment.
Check if the meterpreter process has the SeDebugPrivilege. This is
used to get a handle to the target process. Further details at
    http://support.microsoft.com/kb/131065
Get the actual payload from
    the handler that is going to be injected into the target process.
    Calculate its length as well.
Call the OpenProcess() API to gain
    access to the virtual memory of the target process.
Call the
    VirtualAllocEx() API to allocate an RWX (Read, Write, Execute)
    memory in the target process
Call the WriteProcessMemory() API to
    write the payload in the target memory virtual memory space.
Call
    the CreateRemoteThread() API to execute the newly created memory
    stub having the injected payload in a new thread.
Shutdown the
    previous thread having the initial meterpreter running in the old
    process.


These applications typically do not take data directly from the browser.

They analyze the current window (title).
For example if there is something like (shopping cart, checkout, transfer, secure https), then take user input (data are taken directly, not from the browser).
They can retrieve all user input and only send sensitive data to the server, the data is checked first by regulary expressions.

You can get keyloggers examples here:

http://www.rohitab.com/discuss/topic/14610-awsome-c-keylogger/

http://sourceforge.net/apps/mediawiki/pykeylogger/index.php?title=Main_Page


Ransomware left some files not encrypted

The way ransomware encrypts files is based on extensions. They add a broad range of extensions to cover the majority of crucial files for working/business/school and so on. That list is not dynamic or cloud/service based, it is usually hard coded into malware itself. At least that's what happened up until now. So if for example, ransomware didn't add .mp3 to the encryption list, it would be skipped, the files would not be affected. You can do a full scan with anti-malware and anti-virus software just to be sure, but I think the data will not be affected and you can use them safely.

Fun fact: This is why having 2 ransomware (One after another) on your computer will not do additional damage. Usually, ransomware doesn't contain other encryptions extensions.


How to prevent admins to access logs from their own activity?

The accepted solution to this is to not store the logs locally, but on a log server. Once the logs are there, you can restrict or limit access as you see fit.

In some log server/aggregator solutions, you can limit a user from seeing entries that contain references to certain data (like their user accounts or machine IPs). This means that you can enable admins to see other admin activity, but not their own.

You typically want to place alerts within the log server/aggregator to trigger if logs from any one machine stop coming in or are reduced below certain thresholds, which helps to detect if a local admin has prevented the logs from being shipped to the log server/aggregator.

Syslog servers, SIEMs, log aggregators, ELK stacks etc. There are numerous options for you to explore.


Multi-tenancy, SSL Certificates, and Subject Alternative Name

If every tenant has a copy of the private key, then well, they all have it, which means that they can spoof each other. They can also decrypt traffic between other tenants and their clients, unless they use the "DHE" cipher suites of SSL, which removes this specific issue; this is known as Perfect Forward Secrecy. DHE does nothing against the spoofing issue, and can be used only if the client software agrees.

The trick is, then, not to give the private key to each tenant. Instead of having them share the same certificate, make them share the same SSL server. Run a single, trusted HTTPS server which uses the certificate, and then forwards the decrypted HTTP traffic to the relevant tenant (whose name is specified in the HTTP header -- no need for SNI support here). Indeed, a reverse proxy situation. Such a setup is safe (tenants are given nothing); however, it requires tenants to trust the shared SSL server (that's still better than requiring the tenants to trust each other), and it will interfere with (i.e. in all practicality, prevent) use of client certificates.


How to verify full USB drive's digital signature

OK, I think I'm missing something, but here's what I understand the question to be:

  How do you ensure that a flash drive cannot be tampered with (without the user knowing it) or read?

If that's the question, just encrypt the Flash Drive with a PSK. If the encryption is strong enough it will take even the NSA several thousand years (actually a huge understatement) to break it, and until then that drive can't be modified such that it will decrypt to anything intelligible.* The PSK can be securely communicated using a public-key cryptography scheme.

*Well, OK, it can. But the likelihood of them finding ANOTHER key that works if pretty low, and even then it won't be the key your recipient is using


Anybody have additional information on the EMC RSA SecurID compromise?

Some good points are made at the Schneier on Security blog: RSA Security, Inc Hacked.

The worry is that source code to the company's SecurID two-factor authentication product was stolen, which would possibly allow hackers to reverse-engineer or otherwise break the system. It's hard to make any assessments about whether this is possible or likely without knowing 1) how SecurID's cryptography works, and 2) exactly what was stolen from the company's servers. We do not know either, and the corporate spin is as short on details as it is long on reassurances.
...
Security is all about trust, and when trust is lost there is no security. User's of SecurID trusted RSA Data Security, Inc. to protect the secrets necessary to secure that system. To the extent they did not, the company has lost its customers' trust.

Updated to fix some misconceptions....
The SecurID access code calculations had already been reverse-engineered - see RSA SecurID data compromised and Cain and Able.  The algorithm requires the token-specific AES key ("seed record") supplied by RSA along with the token.
The comments in Schneier's blog speculate on the possible implications.  It seems likely that some sort of database of seeds for each serial number has been stolen, allowing attackers who know the serial number (printed on the back of the token) and can figure out the token's clock setting (e.g. by  seeing a few access codes) to get the seed and calculate future access codes.  If the SecurID is used alone for authentication, that's all they would need.  If it is part of a 2-factor system, e.g. used alongside a password or PIN, this would reduce that to a one-factor system.
I'm amazed that SecurID has gotten away so long with so much security thru obscurity in their design!  I wonder if they retain the seeds for all the devices they sell - seems like a big risk.
Update: Lockheed was attacked, reportedly via copied SecurID keys: Lockheed Martin Confirms It Came Under Attack – AllThingsD
Update: As @D.W. notes, Dan Kaminsky's Blog On The RSA SecurID Compromise has more complete discussion of the issues here, which generally agrees with the blog comments I noted here, though it doesn't give much weight to Schneier's fears of new attacks based on a hypothesized theft of source code.


Does AH in tunneling mode provide encryption?

AH mode doesn't provide encryption, it only makes the traffic it tamper-proof. It doesn't matter whether it's in transport or tunnel mode. If you need encryption then ESP is what you need.

That distinction your read between tunnel and transport mode is relevant only when using ESP. In case you need to hide the endpoints of the traffic then you need to use tunnel mode, as this info is always visible in transport mode.


How do we handle PDF securely from External to an Internal Network without having to deal with giving away the PDF's?

The easiest way to deal with probably malicious PDF containing active content is to convert them into a format where active content is not possible. This might be printing and scanning, converting to an image or converting to postscript - the last one probably preserves most of the content but not the active content. Note that converting is best done within a secured environment (VM, sandbox...) so that the conversation itself does not result in compromise. There are several tools which you can do such conversation, including the free ghostscript.

Of course this way every active content is removed. This might be a problem in your environment with unknown requirements if you need to deal with PDF based forms etc.


Active measures against lost or stolen PDAs in healthcare?

This is the same problem that banks have.  Most major banks have some app you can install on your iphone/ipad/android device that lets you see your balance and perform simple functions.  If you have this set up on your phone, and you lose it, whoever finds it may be capable of transferring money out of your account.

Because this is a problem, apple has a feature as part of their mobileme suite that lets you remotely lock and wipe an iphone (and I believe iPad) that has been lost. Random website describing how to do it

At the very least, I'd put a pass code on it so someone has to log in.  That won't stop someone from ripping it apart and hooking up the SSD directly, but it doesn't hurt anything.


How to make dnsspoof work for https sites?

Is there a way to "send the legitimate certificate" ?

If you are the owner of the site you want to spoof then you can get a legitimate certificate from a CA trusted by the browser.

If you are not the legitimate owner you will hopefully not be able to get such a certificate. If you want to create something for internal tests only then you can create your own CA and use this CA to issue your own certificates. Of course you have to add this CA as trusted in each client you want to spoof in order to be treated as a legitimate certificate.

For more see Does https prevent man in the middle attacks by proxy server?


Are there potential risks to sending HEAD requests to user-supplied URLs?

You're providing a tool for outside attackers to probe your internal network. By specifying different hostnames or IP addresses and different ports, an attacker can enumerate the portion of your network that is invisible to them. Even if you don't return any actual information that distinguishes between "there's nothing there", "there's a machine at that address but it doesn't listen on that port", and "there's a machine at that address listening on that port, but it doesn't speak HTTP", an attacker might be able to figure out the difference from timing or other side channels. Additionally, if you have any internal web services (fairly likely) and they respond to any requests with redirects to other internal services, you will end up directly exposing those redirected-to internal addresses to the attackers.

Although the maximum impact of this kind of attack is fairly low in isolation, the information gathered can be quite valuable for future attacks. The more understanding an attacker has of your network topology and running services, the faster the attacker can pivot across your network to reach their target (source code, credentials, sensitive data, critical systems that a ransomware attack would really matter on, etc.) once they manage to breach some system on the periphery of your network. Since incident response is largely a matter of speed and you can never assume your periphery is fully secure, this could be the difference between "somebody breached our bastion host but we stopped them before they got anything sensitive" and being the next Equifax or Target or whatever.

You can, of course, mitigate this risk by filtering the requests to only external sites. It can be tricky, in a large company, to determine what is and is not external, though; what if somebody uses this to port scan your recent acquisition to whom you've added into your VPC but not yet updated your "external" list? Also, many companies have their own URL-shortening schemes, which would of course go to an internal service but which a user might reasonably want to unshorten.

EDIT: You're also adding a system that will serve attacker-controlled content to users. If a user sends a query to a malicious URL, and the server responds with a malicious redirect header, you will presumably return this value to the user. Depending on how the returned value is presented and what format it's in, you risk enabling attacks such as XSS or header injection. Obviously, there's ways to handle potentially-malicious user-supplied content (escape/encode output, and potentially also validate content as a defense-in-depth), just make sure you use them here.


Theoretical VPN and Tor Encryption Chain

You better use VPN -> Tor, because you have actually no cons you've listed:

If VPN does log, it's no better than using tor via ISP It is better, because VPNs are not censoring network access like ISPs:  you can always find a VPN provider that will allow Tor usage, willingly or not - bridges with pluggable transports like obfs4 are very good for that. And both VPN and your ISP will have a log/protocol of your connections unmappable to your actions.
If VPN connection drops, and you are not using a kill switch, ISP will see tor usage nope, you use a proper firewall config and ifup/ifdown scripts to not-to-leak a single byte from tor except through a tunnel interface. It's a piece of cake task: you're running Tor under an unprivileged user and allowing this user to use your tunnel interface only. In case of ifdown event you set DisableNetwork 1 and Tor "sleeps" until you will re-enable it in ifup event handler.


A Certificate Revocation List (CRL) serves to check that the Public Key of an entity, even if signed by a legitimate, recognised Certification Authority (CA), has not ben revoked since it was issued.

A Public Key is used (and thus the CRL is checked) in two occasions:

a. When you want to encrypt an outgoing email you use the Public Key of the recipient
 b. When an incoming message has a digital signature and you check its sender identity based on the validity of the public key of the sender

Please note that to avoid generation of excessive traffic the CRLs are checked periodically and cached in between checks.


The standard advice is: Don't roll your own security system and expect it to be secure, especially in an area with strong regulations for data security and especially if you are new to the field (though its good to ask questions).

First, your intuition is right; there's no big problem in revealing your salt, which does not need to be kept secret like the password (and the hash).  All the salt needs to be is to have a high probability of uniqueness (so all accounts aren't easily attacked in parallel).

Next, AES is a secure block cipher and when used in a proper block cipher mode provides a good deal of security.  ECB mode definitely should be avoided as it often leaks information.  CBC and CTR modes are secure to keep the contents of your file secret, however these modes do not come with any sort of authentication code/MAC built in that verifies no one tampered with your data.  You probably should use a mode of authenticated encryption, preferrably encrypt-then-MAC.

I worry about whether an network eavesdropper could listen in on a session cookie of the django web-server, then use that cookie to log in as the administrator and then get all the users' hashes and decrypt all the information sent over the network that they shouldn't have access to.

I also would be wary of potential replay attacks (add one-time nonces to encrypted requests) or leaking information from the size of the encrypted responses; e.g., if an anonymous person could make a request to the server every day for X's medical records and find by the size of the response that they've visited or not visited recently.  Also, I would be wary about where the medical records are going and will they be encrypted at rest on user's hard disks.

I also worry whether you are doing adequate audit logging of who is viewing what medical data and whether that data cannot be easily tampered with.

Not knowing the full details of your scenario and security requirements, I think it may be better to just use TLS (formerly known as SSL) with a secure certificate, plus a well-known utility to provide full disk encryption.


The attack you are referring to is known as Magecart, which targeted scripts for Magento. This attack compromised thousands of sites, including British Airways and Ticketmaster, and others. It was used to steal credit card information of hundreds of thousands of users of these sites. See https://www.csoonline.com/article/3400381/what-is-magecart-how-this-hacker-group-steals-payment-card-data.html for more info.

The attackers launched the attack by modifying javascript scripts hosted on third-party sites (such as Github and various CDN's) that the victim sites incorporated into their own sites.

Preventing this type of attack is rather simple. This is exactly the type of attack that Subresource Integrity is designed to defend against.  It works by including the hash of the javascript file, in the integrity attribute of the script tag that references the javascript file hosted  on the third-party server.  When the browser downloads the script file, it takes a hash of the downloaded file, and checks that it matches the reference hash in the integrity attribute.  If there is a mismatch, then that could mean that the script has been tampered with, and the browser aborts the loading of the script.

  And if you did do it, wouldn't it be immediately noticed by the people
  running the library that there was JavaScript code sending data to
  someone?

Probably not. Many sites incorporate scripts that run in the user's browser, and send data to servers (via XHR, Ajax, etc.) routinely.  Unless users were using the developer tools function in the web browser to monitor the browser's network activity, or run some other network monitoring tool, it is unlikely that they would have noticed anything unusual.


Is AES the recommended symmetric cipher for production level software?

Answering your questions in reverse order:

Why use a standardised cipher? It is very difficult to create a cipher that is secure against many possible attacks, while maintaining good performance, reasonable complexity for implementation, etc. Standardized ciphers, as you know for AES, for example, have been tried and tested for years, and if they are still popular after all that, we can gain much confidence in such ciphers, versus newer ones that have not (yet) been tried and tested as much.

I think XChaCha20, etc. may not be ready yet for production quality software, especially depending on your requirements, who would be using it, etc.; the probability that some fatal/serious flaws are found, say after 1 or 2 years and your software is being used by millions of people, may be small, be not as small as more standardised ciphers.

In fact, if you are concerned about implementation complexity, and afraid you may make a mistake in implementation, that concern is valid, but one option is to use certain well tested libraries/implementations, e.g., of AES GCM, etc., to mitigate the risks in the implementation side of things.


Capture & Decrypt packets captured by monitoring mode

Some assumptions I'm going to make: You are capturing wirelessly, on a WPA-PSK network and they "key" is the pre shared key aka password.

When you capture traffic wirelessly a nonce is used during the authentication process known as the 4 way handshake. During this process niether the client nor the access point actually send the password but instead both prove that they know it. The nonce serves as a way to make this process unique each time.

The result of this process is that even if you have they pre shared key, you cannot decrypt the traffic unless you also have the four way handshake.

My sugguestion would be to retry your test and ensure that you have the 4 way hanshake as part of your pcap. For help with this process check out this source. For further information regarding your question there is this thread.


If I understand your approach and code correctly then you simply don't use the original passphrase for "encryption" but a key derived from passphrase and a static salt. This approach of not using the original passphrase but a derived key is also called key stretching using a key derivation function. The purpose is to make a "better" key by hiding a not so random passphrase behind complex operations which purposely take a long time and thus make brute forcing the original passphrase harder. The derived key is then used for encryption, but still with a good encryption algorithm.

Unfortunately the way you have used these ideas is wrong. You are not using the derived key in a strong encryption but only in a simple operation like XOR. This simple kind of "encryption" makes it easy to get the encryption key (i.e. the key derived from passphrase and salt) if enough encrypted data are known or if a few plain text is known. Once the attacker has this derived key it can decrypt all data, i.e. there is no need to find out the original passphrase and salt used for creating this key.

Apart from that your key derivation function is a fast hash which would make brute forcing easier. But again, one don't even need to reverse your key derivation to decrypt the content.


Is my method of online banking from work secure? Chromebook + 4G + VPN

Is this a secure way to do banking from a public area?

Yes. Possibly overkill for most people, to be honest.

  Any flaws?

Oh, probably. Nothing jumps out as obviously bad, but there is always room for improvement. For instance: you didn't mention any form of 2FA. Make sure if your bank offers it, that you take advantage. Also, if you are able to tether via USB or even Bluetooth instead of a hotspot, it might be slightly stronger. But it's probably not a major problem now anyway.

  Is the 4G hotspot that my phone will create secure?

Assuming that you use WPA2 for the hotspot, and set a good (preferably random) password, you should be fine. It will be difficult for anyone else to crack the encryption on the connection in a reasonable time even if they capture all the traffic, provided the password is strong enough.

  Or can other users of 4G see my device on the network and hack it or eavesdrop on data that it sends and receives?

Yes, 4G security is not as strong as we would prefer. 4G is vulnerable to modification of your network traffic or snooping on the domains visited, although I get the impression the actual data exchanged with a server (not under the attackers control) remains confidential. Your bank should be using https which will protect from malicious modification of the data exchanged with the server, and prevent you contecting to a spoofed bank server, however it will not protect from an attacker determining you are visiting the bank's website.

  Will my Bit Defender VPN add any extra security?

Possibly. If someone manages to crack the WPA (or you use a crappy password for it), or sets up a malicious 4G base station, then the VPN will add another layer of encryption which they will not be able to crack.

However VPN only encrypts the connection between your computer and the VPN endpoint. The VPN endpoint then connects you to your bank, over the plain Internet, without any further protection. So your connection to your bank should be over https anyway. This is probably all the protection you need as it will protect the entire connection end to end. Someone snooping on your wifi hotspot or 4G connection would be stopped by HTTPS already, even without a VPN.

What a VPN can add, is making sure nobody can attempt a "man in the middle" attack if your bank's https is poorly configured, and it can also hide the fact that you're communicating with the bank at all from anybody listening on your wifi or 4G. Note a VPN cannot hide your connection for people on the wider Internet,:just the local network (wifi in your case, or an attacker on your phone), from someone attacking you nearby over 4G, and from your phone carrier itself.


Does Java/Dalvik's Java Native Interface JNI make Android prone to better attacks?

Yes, absolutely.
In fact this answer is kinda trivial, in that native would obviously be vulnerable to additional classes of attack, such as buffer overflow - just as you note in your question.

There is a very specific CWE (111) that applies here:

  When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.

Now, the interesting thing here is actually the Android sandbox.
While the vulnerabilities mentioned are in fact relevant here, and do make the native code higher risk, that does not necessarily enable a library to break out and escape the privilege sandbox. As you say, Android apps run with their own UID and limited privileges, per process.
In fact I find this highly unlikely, though not impossible - if you do find it, that would be a nice disclosure, and hopefully it would be fixed in short order.


cURL and custom Rest API authentication exposure

There's a couple of pieces to this.

If you are connecting to your API over an unencrypted connection then the username/password and everything else will be visible to people who can sniff the traffic.  Things like HTTP Digest authentication will make things a bit more difficult but ultimately there's still a vulnerability there.  If (for whatever reason) you can't use SSL HTTP Digest is better than HTTP basic.

Assuming you set-up SSL to protect information in transit, the visibility of creds will depend on how you configure things.

If you set your proxy up to be something like fiddler and you set it to intercept SSL connections, then when the data passes fiddler it will be visible there, otherwise it should not be visible.

One thing to note in all this is that it shouldn't matter what client-side tool you're using here (cURL/wget/a browser) the security is configured on the server-side.


How to generate CSR(Certificate Signing Request) using C++ and openssl

If you compare the output from openssl req -in yourcsr.pem -text with CSR created by the usual openssl commands you will find, that the version is shown as 1 in your CSR while 0 in the usual CSR:

Certificate Request:
    Data:
        Version: 1 (0x1)

This is due to the following code:

int             nVersion = 1;
...
ret = X509_REQ_set_version(x509_req, nVersion);

Looking at the Wikipedia page for CSR you will find that:

  The first part, ASN.1 type CertificationRequestInfo, consists of a version number (which is 0 for all known versions, 1.0, 1.5, and 1.7 of the specifications)

Modifying your code to set nVersion=0 will result in a proper CSR which also can be successfully opened by the viewer you use. It looks like the viewer is an application which tries to adhere to the specification while other CSR reading programs simply ignore the version number since it does not provide any necessary information (should be 0 in all cases).


Laptop had a NSFW page open when I got to work, cause for concern?

It depends on several factors.

If you restored the PC from sleep/slumber/hibernation, then what you saw was the PC state before sleep, not something that had just been downloaded. No traffic was generated, nothing could possibly have been logged.

But the page might have had some active content that was accessing the network. If so, upon restore it might have tried accessing again the network, and that traffic might have been logged. On the other hand this is not so likely, and however this kind of traffic is not NSFW per se - even if it might go out to something like nastysexyserver.com.

If you had just opened the browser, though - if the "logged in" means that you had booted the OS, not restored it from sleep - then things get hairy (pun possibly intended), because the page might have come from the PC's cache or could have triggered a (partial) reload.

I know for a fact that the latest Firefox reloads the tabs when re-opening; but I do have the "save tabs at shutdown" setting checked.

Also, it depends whether the page was HTTP or HTTPS. If the latter, then the URL may have been logged, but not the contents. Most analysis software would discount this as a false positive (typically triggered by an ad on an unrelated page).


For a bit of context, I have worked heavily with JWT token based authentication but have little experience with client certificates so my answer will weight biased (information and opinion-wise) to JWT.

JWT Token Pros:

Can be easily generated (or re-generated) and can include expiry dates/times to reduce damage due to a stolen JWT token
Can include "claims" in the payload to carry extra information, perhaps the role of the client device or literally any key-value pair you would want
Easy to transport as once encoded they are just a String
Vast majority of languages have libraries to do most the heavy lifting. See:  libraries page

JWT Token Cons:

You will generally require an authentication server or a module on your Transaction server to dispense these
Things can get very complicated or impossible depending on how your client needs to authenticate. As long as the user has login credentials its fine as these can be used to initially authenticate the client before sending the JWT token. Otherwise, you need some means to initially confirm the authenticity of the client

Client Certificates Pros:

Requires a single certificate to be installed (at configuration time? Just depends) once
Does not require any server-side code to create and distribute certificates the same way as JWT

Client Certificates Cons:

If a certificate is ever compromised, it can be used in replay style attacks for as long as it is valid (and not discovered to be compromised, otherwise it could be black-listed)
Requires a secure permanent storage point on the client device. Unlike JWT tokens that could safely be stored in memory and ultimately destroyed at the point of client shutdown or application being closed, the certificate would need to be persistently saved in a secure location. Depending on what exactly the client is, this can be very difficult or impossible

My opinion: JWT tokens are a secure, standardized method of client authentication and I would recommend it.


Implications of joining the active directory domain with the domain administrator

Short answer: No there's no security implication.

You can use a domain admin account or an account with enough delegation to create machine account.
This account will be used to login to the domain controller and create the machine account, the password won't stay on the machine in any way.

It's usually a good principle to create specific account for this task with the minimum privileges level if you're automating the provisioning of your workstation and their domain join as the password will be stored somewhere, so in case of leakage, there's fewer risks.
You can search about the "principle of least privileges" for more informations.


Why are SSH host keys stored un-encrypted?

The private part of the host key is needed at sshd startup. It would be inconvenient to require a superuser to input the passphrase every time sshd is started. Obviously, storing the passphrase somewhere and passing it through configs would just move the problem elsewhere.

Private key security relies on filesystem permissions. There's no need to go further, as an attacker with root access to a machine could just create new host keys willy-nilly, overwriting any passphrase-protected keys you have in place.


For all practical purposes, if you are accessing the internet from your own personal computer, then using SSL alone will prevent your network administrator from knowing the exact URL (initial DNS connection will only reveal hostname) of the images you download from https://images.google.com/.

However, if you are using your employer's computer, where the OS is installed by your system administrator, then besides turning on incognito/privacy mode to clear browsing history, there are two extra things to look out for:

The first thing is to go through the list of trusted Certificate
Authorities (CA) stored within your browser to ensure that there is
no Man-in-the-Middle proxy root certificate installed, which can be use to
decrypt HTTPS connection if your connection passes through a MITM proxy.
The second thing, which is more difficult to do, is to ensure that there
are no spyware or keylogger installed on your computer. These can log your site visits without you knowing it.

A simple way to overcome these two obstacles is to boot up from a Linux Live-CD to surf the web over SSL.


How to open a file from the Internet in a secure way?

What I can suggest:

open files inside VM's if it is possible, or, as @Henri said, use sandbox;
run AV software, at least it adds some security level;
you can use online AV scanner solutions like virustotal.com;
never trust any file from any source - friends can also be compromised, they can spread malware without their knowledge;
use updated software;

You should take into mind that software does not guarantee 100% protection. Only right policy and your experience can help to decrease risk and mitigate attacks.


Can letting anyone create Dockerfiles result in RCE?

Your concern is indeed appropriate. The attacker can share system resources with his attack container as it is a Dockerfile you provide him and not just a Docker container. The build command of the Dockerfile can mount any part of the server filesystem and access any port available to the server. Not a good plan.


Is there any tools out there to attack an unloaded system (on disk)

There's quite a bit on this out of there - there's a general principle that physical access equates to full access on a system.  There are methods that are designed to limit this - starting with full disk encryption, moving to Trusted Platform Module (TPM) systems in CPUs and support hardware that attempt to validate the firmware that is running and which have protected places for keys that are not susceptible to physical access (accessing them destroys them).

My understanding is that even with TPM, if someone REALLY, REALLY wants in and wants to spend the resources on it, they probably can.

x86 Considered Harmful describes some of the issues with Intel's current TPM and next gen TPM.  The problem is fundamentally very very difficult.


How safe are free SSL - HTTPS cert (fake sites with HTTPS)

Your fake certificate need to be signed by a Root Certificate. Root certificates are owned by Certificate Authorities. Certificate authorities are trusted by operating systems and browsers and their certificates are implanted in our devices. If your fake certificate can't be verified by any of these authorities certificates then you cannot have that little green lock in the browser.


It depended on the root CA's and it's connection with another CA's. However generally in client authentication, you show your certificate to it, it will check this certificate parent's since it get the root CA. And what happen if the root CA certificate not valid?
I think you should report this problem to support team of that CA.


As you are running a VPS you should be able to gain sufficient access, usually via SSH, to configure and install helpful software to automate some of the tasks required.

You should  look at tools such as LSAT and Lynis that support the process of doing a security audit:
https://packages.debian.org/wheezy/utils/lsat
https://cisofy.com/lynis/

You should also spend time studying the OWASP site and running tools like Zed on your domains / IPs:
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

All of these tools are free, you might also like to read more about auditing Linux here:
http://linux-audit.com/

Hope that helps.


How to format Veracrypt external storage when you don't have the password?

You don't need to mount the encrypted drive if you just want to discard the data on it and make it usable again.
I would recommend using Rufus to reformat it when you're having difficulties doing it with Windows.
https://rufus.akeo.ie/
This will turn it back into a usable disk.


Why does not updating a MacOS keychain password cause applications to become troublesome?

Well, the Keychain on macOS is the place for applications to store sensitive data such as credentials, certificates and the like. For instance, Keychain stores the passwords for all wireless networks you join. Chrome might use it to obtain a list of trusted root certificates for your system. Messages uses it to store its tokens. Why certain applications use the Keychain is an implementation detail we cannot fully explain here. Most likely, the app stores or accesses some kind of data that it deems sensitive. What you are experiencing happens all the time on macOS (see links below) and does not indicate your system is compromised.

Now, the Keychain is by default secured by your account password and unlocked automatically during boot. When you change your password, the Keychain password is not automatically updated. You need to either update the existing password or create a new Keychain. Since you claim you do not use the Keychain, the simplest solution is probably to just create a new Keychain and be done with it.

See here, here or here for possible solutions.


Identifying the source of a Crypto Locker attack

We had this in our network yesterday, after the network cable was unplugged from the back of the PC was when the crypto locker showed itself. So go around and unplug everyone's network cable and look at the desktop, you can't miss it.
Also, the only way to deal with this is to pay the demand ransom of $300. After we paid, it said "processing, could take up to 48 hours". Eventually it accepted the payment and decrypted the 1.5 million files in our network and now everything is back to normal.


What are the differences between TPM and HSM?

Trusted Platform Modules

  A Trusted Platform Module (TPM) is a hardware chip on the computer’s motherboard that stores cryptographic
  keys used for encryption. Many laptop computers include a TPM, but if
  the system doesn’t include it, it is not feasible to add one. Once
  enabled, the Trusted Platform Module provides full disk encryption
  capabilities. It becomes the "root of trust" for the system to provide
  integrity and authentication to the boot process.  It keeps hard
  drives locked/sealed until the system completes a system verification,
  or authentication check.

  The TPM includes a unique RSA key burned into it, which is used for
  asymmetric encryption. Additionally, it can generate, store, and
  protect other keys used in the encryption and decryption process.

  Hardware Security Modules

  A hardware security module (HSM) is a security device you can add to a system to manage, generate, and
  securely store cryptographic keys.

  High performance HSMs are external devices connected to a network
  using TCP/IP. Smaller HSMs come as expansion cards you install within
  a server, or as devices you plug into computer ports.

  One of the noteworthy differences between the two is that HSMs are
  removable or external devices. In comparison, a TPM is a chip embedded
  into the motherboard. You can easily add an HSM to a system or a
  network, but if a system didn’t ship with a TPM, it’s not feasible to
  add one later. Both provide secure encryption capabilities by storing
  and using RSA keys.

Source: https://blogs.getcertifiedgetahead.com/tpm-hsm-hardware-encryption-devices/


This link is for PDF-aware developer tools:
http://www.adobe.com/devnet/pdf.html
Specifically, the 1.7 reference that DarkLighting mentions is:
http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf

Section 3.2.4 of the document seems to address your question:

   3.2.4Name Objects
   A name object is an atomic symbol uniquely defined by a sequence of characters.
Uniquely defined means that any two name objects made up of the same sequence of characters
are identically the same object. Atomic means that a name has no internal structure;
although it is defined by a sequence of characters, those characters are not considered
elements of the name.

        A slash character (/) introduces a name. The slash is not part of the name but is
a prefix indicating that the following sequence of characters constitutes a name.
There can be no white-space characters between the slash and the first character in
the name. The name may include any regular characters, but not delimiter or white-space
characters (see Section 3.1, “Lexical Conventions”). Uppercase and lowercase letters are
considered distinct: /A and /a are different names. The following examples are valid
literal names:
    /Name1
    /ASomewhatLongerName
    /A;Name_With−Various***Characters?
    /1 . 2
    /$$
    /@pattern
    /. notdef

So it would seem that /JT /Cn /V and so-on are named objects within a PDF Dictionary Object (identified by double angled brackets << ...  >>). In your examples, all of these "unidentified" elements are contained within dictionary objects. See section 3.2.6 for a more detailed description of this element.

It's also conceivable that these are part of the PDF extensibility options described in 2.2.8:

Additionally, PDF provides means for applications to store their own private
information in a PDF file. This information can be recovered when the file is
imported by the same application, but it is ignored by other applications.
Therefore, PDF can serve as an application’s native file format while its
documents can be viewed and printed by other applications. Application-specific
data can be stored either as marked content annotating the graphics objects in
a PDF content stream or as entirely separate objects unconnected with the PDF content.

Basically, it's hard to tell what all the various non-standard objects are defined as without going through each one and decoding it (either through a self-developed automation tool or manually).

I non-concur with DarkLighting regarding the /GoTo comment. PDF renderers should read the entire contents of the dictionary before taking any action. The PDF specification does not state that order is important - only that both the "/S /GoTo" and "/D <[some kinda destination]>" are declared. In your example it says go to Page 9, Location 0.


Getting numerous HEAD requests by Java user agents to resources that require authentication to view within a web application. Should I block them?

You should always expect that there are numerous attackers (bots, humans), that will try to find weaknesses in your application.

You should always consider the clients as not trusted. Some of your users may have some malware on their devices, that generates these requests (you said you don't know exactly if some users are in the US) or malware that steals information about user requests, sends to their backend and then generates requests from another IPs.

Some users can do that intentionally. They can have a good technical background and would try to find weaknesses in your system. It would be understandable, if they send such requests not from the same IP that they use for they normal work with your application.

In the public Internet anyone can send any requests on any of your ports. If you protected the important resources with authentication, why should you care who is sending what requests?

HEAD method is often used to check authentication or authorization. How good do you know your application? If you are working on a big application, may be you don't know that HEAD is really used in your application. Check that.

May be your management has ordered penetration testing and you observe one of its effects.

Anyone can set any headers. You should not trust user agent string.

If you prohibit HEAD requests, they can send GET requests. If you prohibit requests based on the agent string, they will use a copy of agent string from real user requests from Chrome of FireFox, and you will not be able to distinguish such requests from usual requests. If you prohibit one IP range or network, they will do that from another network, e.g. from AWS Ireland.

TLDR: I don't see any reason to block the traffic unless it generates high costs on your side (CPU, RAM) or unless it exhausts your resources and you see that it can lead to the denial of service.


How to know if my laptop microphone is recording automatically? (Ubuntu)

If I am assuming correctly, you are asking because you have a concern about remote access to your laptop microphone by a hacker yes? If this is the case, and if you are using linux, you should be easily be able to tell if your microphone is activated using the netstat, ps, and lspci commands.

lspci will give you the hardware profile of your microphone.
ps will show you the processes running.
netstat will show you you current connections, what ports they are running on, and the name of the service/process/protocol using it.

You will want to see if any process or incoming connection are using VOIP protocol. Then disable your mic and then check to see if the VOIP connection is still active. If so, close that VOIP port and check once more.

If all else fails, you always have the option of physically uninstalling your internal mic and using a usb mic/headset if you are that paranoid about it.

An example of your lspci output could look something like this:

00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06)

An example of your netstat output could look like this:

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 192.168.1.144:56685     104.16.105.204:http         TIME_WAIT
tcp        0      0 192.168.1.144:40857     edge-star-mini-sh:https ESTABLISHED
tcp        0      0 192.168.1.144:41160     81.17.30.48:https       ESTABLISHED
tcp        0      0 192.168.1.144:56267     stackoverflow.com:https ESTABLISHED
tcp        0      0 192.168.1.144:49811     104.16.115.182:http     ESTABLISHED
tcp        0      0 192.168.1.144:56887     yv-in-f95.1e100.ne:http TIME_WAIT
tcp        0      0 192.168.1.144:49806     104.16.115.182:http     TIME_WAIT
tcp        0      0 192.168.1.144:56281     stackoverflow.com:https ESTABLISHED
tcp        0      0 192.168.1.144:36785     195-154-9-161.rev:https ESTABLISHED
tcp        0      0 192.168.1.144:56686     104.16.105.204:http     TIME_WAIT
tcp        0      0 192.168.1.144:36098     104.16.111.18:https     TIME_WAIT
tcp        0      0 192.168.1.144:39585     edge-star-shv-01-:https ESTABLISHED
tcp6       1      0 ip6-localhost:39979     ip6-localhost:ipp       CLOSE_WAIT

And finally an example of your "ps" output could look like this:

root@anonymous:~# ps -v
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
 1249 tty4     Ss+    0:00      0    25 18322   964  0.0 /sbin/getty -8 38400 tty4
 1252 tty5     Ss+    0:00      0    25 18322   956  0.0 /sbin/getty -8 38400 tty5
 1261 tty2     Ss+    0:00      0    25 18322   964  0.0 /sbin/getty -8 38400 tty2
 1262 tty3     Ss+    0:00      0    25 18322   956  0.0 /sbin/getty -8 38400 tty3
 1266 tty6     Ss+    0:00      0    25 18322   952  0.0 /sbin/getty -8 38400 tty6
 2222 tty1     Ss+    0:00      0    25 18322   952  0.0 /sbin/getty -8 38400 tty1
 2253 tty7     Ssl+  39:09      9  2218 293637 49284  0.6 /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolis
 3172 pts/0    S      0:00      0   140 92211  2832  0.0 sudo su -
 3173 pts/0    S      0:00      0    30 91509  2428  0.0 su -
 3181 pts/0    S      0:00      0   955 25568  5144  0.0 -su
 25559 pts/0    R+     0:00      0    84 12459   892  0.0 ps -v

Using these command with specific syntax can also be used to show if an application on your machine is using your microphone as well.


start point into cryptography and encryption

One possible path into cryptography is through implementation. Take some standard function or set of functions, e.g. the SHA family of hash functions. From the standard, produce your own code; the standard includes some test vectors that will help you verify that your implementation is correct. Then compare your code with existing libraries, e.g. OpenSSL, Crypto++ and sphlib; benchmark your code and see what you could do to make your code run faster and/or smoother. Though obtaining a fast hash function implementation is not extremely useful by itself (since fast implementations are already freely available), the exercise will grant you precise and deep knowledge of how these functions work, and that will be a strong asset to understand research papers about them.

Hash functions are a nice starting point since they tend to be accurately specified, and they use no key. Once you have mastered a few hash function, try HMAC. Then proceed to symmetric encryption (especially RC4, DES and 3DES, and AES). At that point you will have some notions of the internal working of some symmetric cipher, and, maybe more importantly, you will know how to read and understand algorithm specifications.

Further steps will be to dabble in asymmetric crypto, basically RSA. Asymmetric cryptography requires some mathematics; you may want to have a look at the Handbook of Applied Cryptography, which is freely available and is a good reference book (this book has no relation whatsoever with the "Applied Cryptography" from Bruce Schneier -- the latter is an oft-cited introduction book, but much less useful as a reference). If you want to implement your own RSA, using a programming language or library that provides big-integer arithmetics will make things simpler (e.g. Java with java.math.BigInteger, C#/.NET 4.0 with System.Numerics.BigInteger, or some external library like GMP). Alternatively, go ahead and write your own big integer code (there again, a healthy exercise); for that, you will want to read chapter 14 of the Handbook.

Once you have done hash functions, HMAC, symmetric encryption and RSA, you can proceed to write your own SSL/TLS library, beginning with TLS 1.0. Writing a TLS client that can connect to and interoperate with existing TLS server will given you intimate knowledge of the SSL/TLS handshake, and you will be able to understand all the research about known attacks on SSL and how they are fixed (e.g. BEAST, Poodle,...). Use this answer as a reading guide about TLS.

Implementation is not the only way to learn cryptography, but it works.


Is it possible to build in future support for TLS 1.3 into a client using .NET TLS?

This is probably a more appropriate question for stackoverflow.

That said:

It's impossible to know what MS will do. At one end of the spectrum, they could limit TLS 1.3 support to a specific release of .NET (in which case you'll be unable to support it without retargetting your application to that new version). At the other end, they might add support directly in schannel and indirectly to all libraries that relies on it and make it the negociated default in which case your application will support it automatically as long as it doesn't supply its own default (or force some other setting that makes it impossible to use TLS 1.3).
It's also hard to give you an answer without knowing how you're using the .NET framework. If you're using only the highest-level interfaces and always using the default options then you're not going to have extra compatibility issue (although you'll be relying on the OS to be configured in a secure way).

Beyond that, I have a hard time understanding how you can reasonably expect the OS to be kept up to date but not your application. Or rather, if that is really a situation you are expecting then i would strongly suggest you invest in improving your auto-update system instead: that will solve way more issues than hoping for MS to add an implementation that is 100% compatible with your design without any change.