How can I share files with other individuals using the cloud in a secure way? I would like to use a dropbox because it is easy and convenient.
But I want to encrypt the files with the public key of the intended recipient, so he will be the only one who can access the data in the file.

I have not found an easy mechanism to encrypt the data before it is stored in the dropbox.

Is there an easy way to do so or is there aleady a service that supports my wish?

If you are already settled on using Dropbox, then your only choice at the moment is to use a 3rd party program such as PGP (or free/open GPG) to first encrypt the file and place it into your drop box. I know you said you wanted to use public/private keys, but as an alternative, you could also use 7-zip to create secure archives with AES encryption based on a pre-shared key (password).

If you have not yet decided on Dropbox, you can look at similar online storage systems such as SpiderOak, Cryptoheaven, Mozy or similar, which perform client-side encryption of the files prior to uploading them into the cloud. You control the encryption key, and therefore the storage providers cannot access the data. I am not sure whether you can import existing private or public keys into those solutions or not, however.


Cant see data packets when capturing in monitor mode On linux kali. I got an Atheros wireless adapater. I'm trying to capture data packets off the air and decrypt them as an exercise. I apologize if this question is silly. The problem is that when I turn on the wifi monitor mode and choose an appropriate channel, Wireshark can catch 802.11 management packets such as beacon, probe_request, but it can't catch any user data packets such as the tcp packets. After I turn the wifi back to managed mode and connect to an AP, I can catch user data packets again. Is this the way I should expect Wireshark to behave? Thank you.

This behavior isn't specific to Wireshark but is due to how wireless network cards work. Keep in mind that in monitor mode, your wireless card is completely passive and has no concept of being connected to any particular network. So, if a network is secured with encryption, the card itself won't know how to decrypt those frames and you should just see them identified as 802.11 QoS in Wireshark. Without any additional configuration, you will only be able to see the network traffic of an open (unsecured/unencrypted) network.
However, if it's your own network, you already have the network's PSK, and should be able to decrypt the traffic the way you expect using Wireshark. Note that in order to decrypt a particular session between a device and the access point, you need to capture the 4-way handshake that is performed during initial connection with the network. This can be forced by reconnecting the device(s) or by kicking the target device(s) off the network with a deauthentication attack.
Also, it is likely that you are only capturing your own wireless traffic if running Wireshark while connected to the wireless network.


How does the Signal Protocol, used by WhatsApp, work? I want to understand the process of the Signal Protocol. I have google it, but I am unable to find any good article or tutorial.

I want to understand the basic definition and functionality of the Signal Protocol, and it would be great if any diagram describing the process is available.

Take a look at this technical white paper from WhatsApp, they recently moved to the Signal Protocol for e2e encryption.

Public Key Types

Identity Key Pair – A long-term Curve25519 key pair,
generated at install time.
Signed Pre Key – A medium-term Curve25519 key pair,
generated at install time, signed by the Identity Key, and rotated
on a periodic timed basis.
One-Time Pre Keys – A queue of Curve25519 key pairs for one
time use, generated at install time, and replenished as needed.
Session Key Types
Root Key – A 32-byte value that is used to create Chain Keys.
Chain Key – A 32-byte value that is used to create Message
Keys.
Message Key – An 80-byte value that is used to encrypt message
contents. 32 bytes are used for an AES-256 key, 32 bytes for a
HMAC-SHA256 key, and 16 bytes for an IV.

To establish a session:

The initiating client (“initiator”) requests the public Identity Key,
public Signed Pre Key, and a single public One-Time Pre Key
for the recipient.
The server returns the requested public key values. A One-Time
Pre Key is only used once, so it is removed from server storage
after being requested. If the recipient’s latest batch of One-Time
Pre Keys has been consumed and the recipient has not replenished
them, no One-Time Pre Key will be returned.
The initiator saves the recipient’s Identity Key as Irecipient, the
Signed Pre Key as Srecipient, and the One-Time Pre Key as
Orecipient.
The initiator generates an ephemeral Curve25519 key pair, Einitiator.
The initiator loads its own Identity Key as Iinitiator.
The initiator calculates a master secret as master_secret =
ECDH(Iinitiator, Srecipient) || ECDH(Einitiator, Irecipient) ||
ECDH(Einitiator, Srecipient) || ECDH(Einitiator, Orecipient).
If there is no One Time Pre Key, the final ECDH is omitted.
The initiator uses HKDF to create a Root Key and Chain Keys
from the master_secret.

Receiving Session Setup

After building a long-running encryption session, the initiator can immediately
start sending messages to the recipient, even if the recipient is offline.
Until the recipient responds, the initiator includes the information (in the
header of all messages sent) that the recipient requires to build a corresponding
session. This includes the initiator’s Einitiator and Iinitiator.

When the recipient receives a message that includes session setup
information:

The recipient calculates the corresponding master_secret using
its own private keys and the public keys advertised in the header of
the incoming message.
The recipient deletes the One-Time Pre Key used by the initiator.
The initiator uses HKDF to derive a corresponding Root Key and
Chain Keys from the master_secret.


Cloudflare's free SSL options require trusting them; what could they do to change that? Cloudflare offers 3 free SSL options: Flexible SSL, Full SSL, and Full Strict SSL.

The article “CloudFlare’s great new features and why I won’t use them” explores the shortcomings of the Flexible and Full (non-strict) SSL options.

The Full Strict SSL option encrypts clients’ connections to Cloudflare, and also Cloudflare’s connection to origin server — for which a Valid CA signed certificate is required. However, even with this option selected for your site, Cloudflare must be trusted, as they are the middleman, receiving the data, decrypting it and then encrypting it on its way to the origin server — and vice versa. Additionally, they must be trusted to actually require valid certificates from origin servers.

So, this setup allows Cloudflare to monitor, record, and modify any traffic between clients and the origin servers.

The fact that they can do this is a huge security concern, is it not? It cheapens the SSL system by appearing (to an average user) that your connection to the site you are visiting is secure cryptographically end-to-end, rather than the reality, whereby trust in Cloudflare is required.

How could Cloudflare offer SSL without requiring users to trust them?

From what I understand, no, Cloudflare couldn't work any other way.

Cloudflare analyses the connection before passing it to your webserver to ensure that it's correct and coming from a legitimate client.  In order to do this, it needs to be able to see the contents of each packet from and to your server.

With SSL/TLS, each packet is encrypted and therefore not visible to Cloudflare.  It needs to be able to decrypt any traffic before it can analyse it.  To do that, it needs to have the private key for the cert used to encrypt the traffic.

The only way around this I see, is if Cloudflare sold its application that you could then self host.  That still requires trusting the application (it may forward information to Cloudflare's servers, for instance), but at least it wouldn't be hosted elsewhere and totally out of your control.  This would be a trade off, as you'd lose Cloudflare's distributed network.  You would still have some benefits (anything implemented in software e.g. SQL injection protection), but would lose anything relying on the large network  capacity (e.g. some DDoS protection).


Are there known security issues with Cuckoo website? Having decided to learn about sandboxes and download Cuckoo, Avira tells me that this is a malware site that can infect my computer:

https://cuckoosandbox.org/ -> click "Download Cockoo!" -> Avira warning, blocking the download website

I am little bit astonished since Cuckoo seemed to have a good reputation and is even mentioned positively in AVIRA blogs (https://blog.avira.com/cuckoo-sandbox-vs-reality-2/ and https://blog.avira.com/vmcloak-create-virtual-machine-easy-way/, so I think this might(?) be a false alarm.

Questions: Are there any known security issues with Cuckoo and the Cuckoo website itself? I Would be surprised, but are there download sites safer than the genuine (please correct me if this is a fake site)  https://cuckoosandbox.org/?

System information:
Win-10, Firefox 52.0.2,
Avira free, version 15.0.25.172 (in AVIRA help, there is usualle just the answer that trusted websites can be unblocked, but my question is how to tell if trustworthy in this special case)

There are generally two kinds of website security alerts:

Blacklist-based, where a threat researcher or server-based scanner determines a page is bad based on thousands of potential criteria, and distributes its findings to clients. Because both humans and machines are making judgement calls, there's plenty of opportunity for legitimate sites to be blacklisted. This is especially prone to happen on security-themed websites since they discuss and include scary-looking things
Client-side script scanning, where the antivirus locally scans and emulates JavaScript in real-time to determine if a website is bad. These results are usually more exact and reliable, but still open to false-positives.

It appears this alert is the first, a blacklist-based detection. It's not surprising a computer security website where you download something to do malware analysis is miscategorized as malware.

Additionally, I've examined the website and run it through URLquery.net and it seems clean to me. I wouldn't worry about this.

Regards,
Swift


How does TLS over NFC works? I'm reading about NFC and how its security can be enhanced. I read somewhere that it is possible to use TLS over NFC. Unfortunately, I can't find any more information on that topic.

How does TLS over NFC works ? Is it something standardised ?

Standardized?  Well, that depends; there are a lot of standards involved.

Amusingly, someone did, in fact, get IP to run over NFC (both UDP in the form of DNS requests, and TCP in the form of - you guessed it - HTTPS)!  Sockets over NFC on Android on the classycode.com blog lists how in more detail.

Their code is on github with an Apache 2.0 license.

Highlights include:

In our case, we want to exchange these messages over NFC, using ISO/IEC 7816–4 APDUs, between an Android smartphone (the socket client) that supports Host Card Emulation and an NFC reader connected to the Internet (the socket provider)

...

The socket provider is a RaspberryPi with a PN532-based reader connected via SPI. It’s connected to internet via Wi-Fi. This turned out to be a great setup for playing with NFC. For short instructions on getting the setup to work, see my last blog post.

...

The application is written in C and uses libnfc to access the NFC reader. It has no other dependencies, and is fairly compact. It consists of three modules:

pn532_socket_tunnel.c
Manages device connection, handles incoming messages.
socket_infos.c
Encapsulates the application’s state in a fixed-size table of socket infos, i.e. open file descriptors, pending read/write results, statistics.
messages.c
Parses incoming messages and assembles outgoing messages.

...

Now that we have a provider that exposes sockets via APDUs, how do we use it on Android? We can leverage a couple of useful things:

java.net.Socket can be subclassed, so we can provide a NFCSocket implementation that overrides the default behavior.
javax.net.SocketFactory is a facility for providing custom socket implementations.

...

We chose okhttp as HTTP Client library as Android’s HttpURLConnection does not provide a means to provide alternative SocketFactory instances on a per-connection basis. We also disable timeouts as our NFCSocket does not support them yet.

...

Android/Java does not provide a way to override DNS lookup, but fortunately for us, okhttp allows pluggable DNS via the Dns interface:

...

Of course we don’t want to write our own DNS client, so we just use the MiniDNS library instead.

...

The Graz University of Technology offers a commercially licensed, pure-Java JSSE called iSaSiLk which is freely available for Open Source projects. Special thanks to Dieter Bratko for providing me support for iSaSiLk!

...

Success! We downloaded the Hacker News front page via NFC, securely, including the stylesheet and image resources in just over 30 seconds. Which is an eternity of course.

With a Google Pixel and the PN532 reader chip, we get a measly bandwidth of around 1.5 KB/s. Yes, you can browse the web with this. You can even do so securely. But you won’t enjoy it.


What features do you look for in an Enterprise Log Management solution? This question is for IT Pros, and people who manage a company's infrastructure. Developers should see this related answer for tools geared for them.

What are your requirements for such a Event Log Managment solution?  What do you currently, or do you hope to derive from such a system?

More info:

I found a related question that focuses on how an application should save to the eventlog, but this question is orthogonal to that.  Here I'd like to what tools, reports, and surrounding alerts you want from a system that aggregates, and analyzes log files.

In an Enterprise setting this would undoubtedly include: Windows Event Logs, Firewall, Router logs, syslog, etc.

Here are a few different features you should consider, note that you might not need all of these, and one might not be better than the other - but they are points to consider:

Coverage:

Windows Event Log on servers, all current versions
Windows Event Log on clients, all versions in your org (you'd be surprised how many Win98s there still are...)
syslog on Linux/Unix servers according to your flavors
syslog on Linux/Unix workstations (if you have) according to common flavors in use
generic SNMP traps
Other OSs you might have...
Network equipment (if thats where you want to take it): Firewalls, routers, gateways, proxies, WAFs, IDS/IPS, etc
Web/App server logs: e.g. IIS, Apache, WebSphere, WebLogic, etc, whatever else you have
Databases
Mail servers
MQ servers if you have them and they are critical
AD/directory/IdM servers
security and control servers, e.g. content filtering gateway, HPOV, MS SMS, etc.
etc any other infrastructure you find critical
Application logs! As I said in my comment up top, this are of critical importance, yet are most often neglected. While there is no real common format (there are some structures but nothing data-specific), the SIEM product/solution should:
a. be able to receive and generically parse a variety of formats and files, e.g. CSV, XML, flatfiles, etc.
b. ideally would be able to define specific formats and recognize the data

Agent vs agentless (aka push vs. pull)

There are advantages to each, which is better really depends on your specific environment.
Best would be support of both models, and use each where appropriate
Even bester is support of a builtin API to log directly to it.

Aggregation and consolidation
Correlation - i.e. link different events from different sources together to form a single meaningful incident. Ideally should use a variety of techniques
Reporting and dashboards - should be BI-like, both for trend analysis and specific incident/user investigation
Automated analysis and active alerting, depending on configuration. Should be flexible enough to fit your needs and expectations. Analytical engines should be able to identify certain classes of misuse/fraud/attacks in (near-)real time.
Historical data, and reports/analysis/correlation over time
If its relevant, some products offer "Compliance" packages, to assist in meeting specific regulatory requirements.
high availability
Ample protection of log data, both its confidentiality and its integrity, using combination of encryption, access control, self-logging, etc.
Remote management (securely, of course)
Possibility to plug into SOC if/when you get there


How to identify malicious Wordpress user agents I have noticed our website, which is Wordpress based, gets frequent daily requests from other sites where the user agent is Wordpress and the other site is obviously an already hacked Wordpress installation.

In these entries I have replaced our own domain with example.com and purpleplumm.co.za is one of those compromised sites.

105.233.38.37 - - [05/Dec/2019:12:14:44 +0000] "HEAD /services/ HTTP/1.1" 200 6102 "https://www.example.com/services/" "WordPress/4.9.12; http://www.purpleplumm.co.za"
105.233.38.37 - - [05/Dec/2019:12:14:45 +0000] "GET /services/ HTTP/1.1" 200 7136 "https://www.example.com/services/" "WordPress/4.9.12; http://www.purpleplumm.co.za"

I assume these are a sort of malicious worm trying to propagate through unsecured Wordpress installations?

I was going to block these requests by checking the user agent with a regex in Apache.

RewriteCond %{HTTP_USER_AGENT} ^Wordpress/\d
RewriteRule .* - [F]

I have two questions:

Is my method sufficient to block them?
Does anybody have any further insight into what they are trying to achieve with these requests? The requested resources don't seem to be common access points on a Wordpress installation (e.g. login/admin pages) or anything like that, just random pages of the site.

Edit: I forgot to add that I have lots of other security measures already in place; this is just something extra I was going to add.

Your method is sufficient to deter most automated scanning attempts of this nature
They are most likely probing for weak plugins.

Your best bet is to minimize the use of plugins, and keep everything up-to-date automatically.


Work internet redirecting to Twitch? When connecting my laptop with the work LAN, I noticed that certain websites get redirected always to a twitch channel.
I have changed the DNS configuration and used 8.8.8.8 and 8.8.4.4, but the problem is persisting.

However, when I connect my laptop to another internet source and with the same DNS configuration, the problem disappears and I get redirected to the right website.

What are the possible sources of the problem?
Are the work LAN routers infected?
Why is it happening only in some websites?

There are lots of potential reasons for this. It could be a misconfigured DNS, the firewall, a work-installed agent on your machine. Or someone on the local network is maliciously redirecting traffic. A network tech might have configured the firewall to redirect certain sites to their favourite Twitch channel so that their browser history looks work-related, but doesn't realise that the entire network is affected.

There are a lot of potential reasons for internet traffic to go to unexpected places.

We cannot tell you the source of the problem from your description alone or why it is only happening on certain sites. Someone with networking knowledge would have to run a packet capture to start to run down the problem.

You need to be working with your IT team. They are the appropriate people to ask about this.


Do browsers send cookie on Cross Site GET request? I am able to make cross site requests because I have enabled CORS. I read about CSRF vulnerability which is caused by the fact that browser sends cookie when making a form POST request.

I tried to exploit my website to see if it works. Therefore, I tried with something simple first. I sent a cross-site GET request but no cookie was sent. So, my question is do browsers not send cookies at cross site GET request or is it that I did something wrong?

In order for cookies to be sent with cross-site requests, .withCredentials must be set to True in the cross-site request.  See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS for more info (scroll down to the section 'Requests with credentials').


Would it be possible and advisable to create a worm to patch for WannaCrypt? WannaCrypt uses an SMB vulnerability to spread. Can we not use this vulnerability to create a similar worm, but one which patches for WannaCrypt instead of affecting it.

Our worm infects a computer on network using the same vulnerability.
And then spreads itself to other computers on the network.
Then patches the infected computer.

Ignoring potential legal issues, is this advised?

To make sure our worm doesn't go out of control, we can rate limit it or ask it to stop by validating a domain (similar to WannaCry).

The aim is not to reverse the damage done, but to protect unpatched PCs from being infected by WannaCry.

Is this method even advisable? Not just against WannaCrypt but against any other similar but worms.

That would definitely possible. In fact, a couple of days ago it was discovered that, even before the WannaCrypt outbreak, another piece of malware was infecting computers using the ETERNALBLUE exploit and secured the systems against ETERNALBLUE afterwards. (Said malware didn't install the patch, however; instead, it blocked the port used by SMB.)

But, it wouldn't make much sense for a vigilante to create an anti-WannaCrypt worm at the moment; at this point, WannaCrypt has already spread so widely that pretty much all targeted systems that are connected to the internet have either been patched or got infected.

(Although, because WannaCrypt crashed when infecting XP computers, those could still have escaped infection without being patched, there will probably still be some unpatched XP computers out there that could be targeted by an improved version of WannaCry or similar malware.)


Can I throw away a private key and use the public key like a hash function? Yes yes I know "don't invent your own protocols unless you're an expert". No need to yell at me I just want to know if there's a flaw in this idea and if not has anyone done it before.

The motivation here is I want to be able to authenticate users. I know that the standard solution is to salt and hash passwords. But I don't like the fact that the password itself must be sent to the server to check it. What if someone listens in? The client side can encrypt and send the password, but I don't like that either because maybe my decryption key leaks and someone who recorded previous web traffic can deduce all the passwords. Authentication is not a novel problem so I won't dwell any further on the pros and cons of the usual solutions.

My idea

For each user (a) the server stores a public key (g^x_a) and the password encrypted with that public key (g^{x_a} * p_a). The associated private key was either promptly destroyed or (better still) never calculated. The group generator g is held on to for future key generation. The usual relation applies g^a * g^b = g^{a+b}. The authentication process is as follows

The user Alice asks to be authenticated
The server Bob generates a new temporary public key g^t (again without an associated private key). Bob multiplies this temporary public key on his Alice data. This results in g^t * g^{x_a} = g^{t + x_a} = g^{x_a}' and g^t * g^{x_a} * p_a = g^{t + x_a} * p_a = g^{x_a}' * p_a. Bob disposes of the temporary public key leaving him only with a new public key (g^{x_a}') and Alice's password encrypted with this key. He sends the new key to Alice.
Alice takes the key given by Bob uses it to encrypt her password. She sends the encrypted value to Bob.
Bob authenticates Alice if the value given matches with the encrypted data calculated in step 2.

To recap

At no point in time can the server (or a database hacker) decrypt the password. With the private keys gone the public key encryption effectively works like a hash.
Since each user is encrypted with a different key, the passwords are effectively salted. A rainbow table would not work here.
A hacker with a previous image of the database cannot deduce future values of g^x_a * p_a by listening in on web traffic since that would require deducing the temporary key (which requires solving discrete log). Thus a leaked database image does not allow an attacker to impersonate users.
Neither the server nor the client has any private keys to manage. Only the client needs to keep secret information and the secret information can be human readable.
(drawback) an attacker has a small window of time between steps 2 and 4 where he can penetrate the server and impersonate a user using the data he found.

A very "easy" problem about (any) transport encryption of passwords:

Sending it in plaintext over HTTP, of course any sniffer can read it, and use it to login.
Sending plaintext over HTTPS (where all data is encrypted, not just the password alone) is already ok.
Sending encrypted password within HTTPS offers no benefit.
And encrypted passwords over HTTP (and the server expects it encrypted): There you still have the problem that a sniffer can read the encrypted password, send it to the server himself, and successfully log in.

So, tell me, why are you encrypting passwords during transfer?

About your combination of public keys, with RSA-OAEP etc. this just won't work (if you have never heard of OAEP, you should just know that plain RSA is not secure).

There are other problems, but these two alone make your scheme useless already.


How can the german ChipTAN / CardTAN system be secure? The german ChipTAN (https://en.wikipedia.org/wiki/Transaction_authentication_number#ChipTAN_/_CardTAN) system calculates a TAN that is send to the banking server to proof the transaction. The number is usually 6-8 digits long. But how can this short number be secure?

In my opinion a secure TAN has to be calculated from the receivers bank account number, the transfer amount, the date/time and a secret that is only known by the bank and the user.

But how can this all be calculated into 8 digits? In my oppionion this is highly vulnerable to collision attacks. And I also think that the secret could be easily calculated if an attacker can catch multiple TANs. If an attacker could catch multiple TANs and also knows the algorithm he can find a key that can reproduce those TANs. And there is a high chance that this value may work for new TANs as well.

Is this system as vulnerable as described? Or do I misunderstand something?

In my opinion a secure TAN has to be calculated from the receivers bank account number, the transfer amount, the Date/Time and a secret that is only known by the bank and the user.

From the Wikipedia article you refer to "The TAN generated is specific to the bank card as well as to the current transaction details. "

  But how can this all be calculated into 8 digits? In my opionion this is highly vulnerable to collision attacks.

Collision attacks only matter if you can do a brute force attack against the system asking for the TAN. I'm not sure about exactly this system but it is common to both limit the amount of queries from one system and also limit the number of tries in total. My guess is that you have only a single or a few tries to guess the TAN and if this fails you have to create a new TAN based on new transaction details (i.e. new time).

  If an attacker could catch multiple TANs and also knows the algorithm he can find a Key that can reproduce those TANs.

This argumentation is wrong. For example take a simple algorithm like sha256(secret + transaction_details): even if the secret is always the same and you know some transaction details and some output TAN's you will not be able to compute the secret with reasonable costs and time - i.e. reasonable meaning that the costs is lower than the gain and the secret has not been changed already after your computation is done. And, it is easy to harden the algorithm even more, just look at password hashes.


How can one make sure that some specific directories are fully deleted (without any record of their deletion) from a USB/flash drive? It seems data resides in USB somewhere until it's completely overwritten. But is there a way to delete big directories 10-100GB or so without zero-filling the remaining space and only eradicating those specific directories? Would the history of deleting those is eraseable too?

Can someone when recovering deleted data also know when the file was deleted (not when it was last written but deleted)?

Not really - it's the same problem as with SSDs, in that the way flash memory works in both USB drives and SSDs involves a certain amount of overcapacity and the ability to mark certain areas as unusable. There is always a risk that data remains in a currently unusable area of the device, but which could be recovered by specialist tools.

Best option is usually to encrypt the whole drive before putting any sensitive data onto it, then only encrypted data will be left on any currently inaccessible sectors, which, without the rest of the data and the key (assuming a sensible cipher mode), should be impossible to turn back into useful data. If you already have sensitive data on the device which you need to be completely unrecoverable, only real option is physical destruction.


Java KeyStore vs OpenSSL implementations of pkcs12 files -They seem to differ. Do they? I generated a pkcs12 keystore in Java and wanted to inspect it with OpenSSL, but OpenSSL threw back an error. After a bit of head scratching I realized that the KeyStore format in Java allows you to have different passwords on the store itself and the pkcs8 encrypted key inside, while OpenSSL seems to assume that both passwords have to be the same. I can easily inspect a pkcs12 file created in Java if both the file and key passwords are the same, but get an error when they differ:

Bag Attributes
    friendlyName: usercert
    localKeyID: 54 69 6D 65 20 31 35 38 38 30 32 32 30 31 38 30 37 31
Error outputting keys and certificates
139815467680960:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:../crypto/evp/evp_enc.c:570:
139815467680960:error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error:../crypto/pkcs12/p12_decr.c:62:
139815467680960:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error:../crypto/pkcs12/p12_decr.c:93:

Have I missed something or is it correct to say that the pkcs12 impementations differ slightly?

I'm looking for a way to be able to inspect pkcs12 files with OpenSSL where the two passwords differ. Any help would be appreciated.

TLDR: yes, this is a difference. Note the Java KeyStore API allows different passwords, but the keytool commandline program rejects attempts to create a PKCS12 with the keypass different from the storepass, precisely because such files are not interoperable.

But if you really want, you can extract the information, mostly following https://stackoverflow.com/questions/51242721/openssl-debugging-how-to-dump-intermediate-asn-1-inside-openssl

$ ll se230* # this file created by Java with keypass different from storepass
-rw-r--r--. 1 [redacted] 1506 Apr 28 01:24 se230650.p12
$ openssl pkcs12 <se230650.p12 -passin pass:sekrit   # and gets your error
MAC verified OK
Bag Attributes
    friendlyName: mykey
    localKeyID: 54 69 6D 65 20 31 35 38 38 30 35 31 34 35 32 31 36 34
Error outputting keys and certificates
139841232930632:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596:
139841232930632:error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error:p12_decr.c:104:
139841232930632:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error:p12_decr.c:130:

First get the cert(s), which use the storepass so OpenSSL can handle them -- and verify the MAC:

$ openssl pkcs12 <se230650.p12 -passin pass:sekrit -nokeys
MAC verified OK
Bag Attributes
    friendlyName: mykey
    localKeyID: 54 69 6D 65 20 31 35 38 38 30 35 31 34 35 32 31 36 34
subject=/CN=dummy
issuer=/CN=dummy
-----BEGIN CERTIFICATE-----
MIIBjjCB+AIBezANBgkqhkiG9w0BAQUFADAQMQ4wDAYDVQQDEwVkdW1teTAeFw0y
MDA0MjgwMTI0MTFaFw0yMTA0MjkwMTI0MTFaMBAxDjAMBgNVBAMTBWR1bW15MIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzAzdcre9ENIictTSr87E/0B7G6AYi
BA9BrBCXh8TMHjbXdIDEJT0TvrRqO2pt1y2QCtoqUcW1sZTEmNIIdZzmQZvsfwy7
BB/ZOo7NqVj2MMBwYw50BU/L+ZDBQafTPs+AjvlvWRDMs/JkWQj/skR3vY6KJf51
FKbKuzHHQxuJzwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAC1IvPSY/2P2+AKlMm48
CmrZLYMqkHFRYCWhOJt2XcbVhHhNYOD3DVZOPIJuKBGqDyGJIQEPvsptvBlH7F+X
VEeRcAVVSCd9zG43WrPBakoxAKsq53lBVq0h2EYJtkcoh1cjJa1zVWJFd8+FF8x7
da047UEJC5TQX6jlkSt3kAmm
-----END CERTIFICATE-----

Now look at the file:

$ openssl asn1parse -i -inform d <se230650.p12
    0:d=0  hl=4 l=1502 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim:  INTEGER           :03
    7:d=1  hl=4 l=1432 cons:  SEQUENCE
   11:d=2  hl=2 l=   9 prim:   OBJECT            :pkcs7-data
   22:d=2  hl=4 l=1417 cons:   cont [ 0 ]
   26:d=3  hl=4 l=1413 prim:    OCTET STRING      [HEX DUMP]:30820581[BIG snip]
 1443:d=1  hl=2 l=  61 cons:  SEQUENCE
 1445:d=2  hl=2 l=  33 cons:   SEQUENCE
 1447:d=3  hl=2 l=   9 cons:    SEQUENCE
 1449:d=4  hl=2 l=   5 prim:     OBJECT            :sha1
 1456:d=4  hl=2 l=   0 prim:     NULL
 1458:d=3  hl=2 l=  20 prim:    OCTET STRING      [HEX DUMP]:[snip]
 1480:d=2  hl=2 l=  20 prim:   OCTET STRING      [HEX DUMP]:[snip]
 1502:d=2  hl=2 l=   2 prim:   INTEGER           :0400

and find the authSafe:

$ openssl asn1parse -i -inform d <se230650.p12 -strparse 30
    0:d=0  hl=4 l=1409 cons: SEQUENCE
    4:d=1  hl=4 l= 798 cons:  SEQUENCE
    8:d=2  hl=2 l=   9 prim:   OBJECT            :pkcs7-data
   19:d=2  hl=4 l= 783 cons:   cont [ 0 ]
   23:d=3  hl=4 l= 779 prim:    OCTET STRING      [HEX DUMP]:30820307[BIG snip]
  806:d=1  hl=4 l= 603 cons:  SEQUENCE
  810:d=2  hl=2 l=   9 prim:   OBJECT            :pkcs7-encryptedData
  821:d=2  hl=4 l= 588 cons:   cont [ 0 ]
  825:d=3  hl=4 l= 584 cons:    SEQUENCE
  829:d=4  hl=2 l=   1 prim:     INTEGER           :00
  832:d=4  hl=4 l= 577 cons:     SEQUENCE
  836:d=5  hl=2 l=   9 prim:      OBJECT            :pkcs7-data
  847:d=5  hl=2 l=  40 cons:      SEQUENCE
  849:d=6  hl=2 l=  10 prim:       OBJECT            :pbeWithSHA1And40BitRC2-CBC
  861:d=6  hl=2 l=  26 cons:       SEQUENCE
  863:d=7  hl=2 l=  20 prim:        OCTET STRING      [HEX DUMP]:[snip]
  885:d=7  hl=2 l=   2 prim:        INTEGER           :0400
  889:d=5  hl=4 l= 520 prim:      cont [ 0 ]

and the first safebag, which contains the keybag:

$ openssl asn1parse -i -inform d <se230650.p12 -strparse 57
    0:d=0  hl=4 l= 775 cons: SEQUENCE
    4:d=1  hl=4 l= 771 cons:  SEQUENCE
    8:d=2  hl=2 l=  11 prim:   OBJECT            :pkcs8ShroudedKeyBag
   21:d=2  hl=4 l= 690 cons:   cont [ 0 ]
   25:d=3  hl=4 l= 686 cons:    SEQUENCE
   29:d=4  hl=2 l=  40 cons:     SEQUENCE
   31:d=5  hl=2 l=  10 prim:      OBJECT            :pbeWithSHA1And3-KeyTripleDES-CBC
   43:d=5  hl=2 l=  26 cons:      SEQUENCE
   45:d=6  hl=2 l=  20 prim:       OCTET STRING      [HEX DUMP]:EF7420960D29A9A2E69AE4FD35A6ACBE87F46BD0
   67:d=6  hl=2 l=   2 prim:       INTEGER           :0400
   71:d=4  hl=4 l= 640 prim:     OCTET STRING      [HEX DUMP]:[big snip]
  715:d=2  hl=2 l=  62 cons:   SET
  717:d=3  hl=2 l=  25 cons:    SEQUENCE
  719:d=4  hl=2 l=   9 prim:     OBJECT            :friendlyName
  730:d=4  hl=2 l=  12 cons:     SET
  732:d=5  hl=2 l=  10 prim:      BMPSTRING
  744:d=3  hl=2 l=  33 cons:    SEQUENCE
  746:d=4  hl=2 l=   9 prim:     OBJECT            :localKeyID
  757:d=4  hl=2 l=  20 cons:     SET
  759:d=5  hl=2 l=  18 prim:      OCTET STRING      :Time 1588051452164

and since it is a PKCS8-encrypted, as it should be, just copy it:

$ dd if=se230650.p12 of=se230650.key bs=1 skip=82 count=690
690+0 records in
690+0 records out
690 bytes (690 B) copied, 0.0020009 s, 345 kB/s
$ openssl pkcs8 -in se230650.key -inform d -passin pass:foobar   # note different pw
-----BEGIN PRIVATE KEY-----
MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBALMDN1yt70Q0iJy1
NKvzsT/QHsboBiIED0GsEJeHxMweNtd0gMQlPRO+tGo7am3XLZAK2ipRxbWxlMSY
0gh1nOZBm+x/DLsEH9k6js2pWPYwwHBjDnQFT8v5kMFBp9M+z4CO+W9ZEMyz8mRZ
CP+yRHe9jool/nUUpsq7McdDG4nPAgMBAAECgYBp+y17oT5WkwOOQ3m7k7sMnJqc
CCIZYW3m44evLqJEdl7hkAfsGF/goLcPbb3E6e//p20iQOdcepYpDpDKkVchunRX
NPM4BcdGy9Df/V+u1PpfY4ZQeGVYfQe4Aeg+8gMJKvKK3fhLqapqgPmR0KJPUKPo
DXYH3DoqwPM9sXSHAQJBAPqZrwpfIBIVz+VZ+r6IZebNeQuMaPdIXDYEPsBX9E5Q
0NzWaGyvUxku31NBwDLJD949Q68BKn4IX6sidWOqFGkCQQC23qcsML1NCudR4hZH
0kcZpOxgcYxiBaLXtfbhzG8ujiGCqPQGAz7ldw/Endjs0n+2BP+ezQMaxnzUiIUK
tgV3AkEA6x0rM7Dh1vXt8kGEViSEbpGSonoetPqHwQokkbMzfBKokrj6ihXIAhWO
438JwtwO7jROfy+53Tsf/uC6gEI/GQJBAJLGKFU+lWGVw84j8ZAZxTle9t39pRgz
v9z0zr+yrvYl292cL6f3yO6x3jUIIEkMNrboUiaqE7jU4PJQ1L+hEscCQC1IXh1X
1CL1ZGvyEqQCgk8ODxDpTAGIQRpi3zy3nO4hanaxiDgaEhAiwwqL2uJn4cjssQg8
q9TTgH0RrLGrZ50=
-----END PRIVATE KEY-----
$ # add -passout pass:value (or other option) if you want the output privkey encrypted

Here's a copy of my file if you want to test/compare for yourself:

$ openssl base64 <se230650.p12
MIIF3gIBAzCCBZgGCSqGSIb3DQEHAaCCBYkEggWFMIIFgTCCAx4GCSqGSIb3DQEH
AaCCAw8EggMLMIIDBzCCAwMGCyqGSIb3DQEMCgECoIICsjCCAq4wKAYKKoZIhvcN
AQwBAzAaBBTvdCCWDSmpouaa5P01pqy+h/Rr0AICBAAEggKANIjyFsrUNyha6efL
99Fx6/cQixa8Qmmio3s8JzhFP6q2fTHYi8XyRuItDK7XSIdEhtFTIK8OUWI7Keo0
M3TYB4XlkSrsyK0U5j75tyvDc3nohFxzFWJe6Rf4N7uG5LRZduS4K5UZoSPXfCkC
yJeKEzIBt4e3XgYjiEvNpkcroG2r6hdDO3N19cqhq6ZYy9L2f8uZc8NATJZswO6t
CeS1lsc2AH2ZWyKUFzCeDSxRuOxdzN0En9aty9kTENkm34LD1QfJSyjrs5Y0Byxj
ExLNl0dscmQFpA3SK5FL1wMvxJ64D2gA857kLyOk/m9VQp8LJ7I+oTaMQtlHRto/
Ku8Jy/6vatl+jS9+OR3UOG+H1VN8e0SVVuqA0cpU6hrsa5ap15vAEwRKrZIK4typ
7ZRFZ4jviGJp/wB8wlPySvL3UiXizNNATihDOJiUZxP4BVyAtBJgz6o6rtjTjcEU
dIpN1Q9OsD46X5LD6qD2psJEo3WyRwAHfc/BnBrGaezsX1RKLgfR32o7ef/5QOwB
0KMqnnvNBXE6PFdGQho0bf+Fn2pM1s0RPivdAVuqkaAgEKsjUWEqetnGwt2rBEuU
EQdUc8zEc4jylZZIANd6u8KXc7Fqraa8hV8jqRHceeji8l6w6YzQ82UhDccOTW3Q
6+yrMmmhyR4VW9/D9RBunlnpG9kK4XLttcu//ZnvHT8goT5HziSUrK5PWv/5xR04
bVLjEQbXNdsl5UCag5+VEruUJefWr9Y0ZC7CEyJixqtZr6O7tJfZ493Y6iC8Mo9C
7NPDi82oJA/A+pgnUVY2pj8jCF1QtEQJdHnX0bw11wrirER6Y0l9iFuwVQFxGHZ+
WvJLojE+MBkGCSqGSIb3DQEJFDEMHgoAbQB5AGsAZQB5MCEGCSqGSIb3DQEJFTEU
BBJUaW1lIDE1ODgwNTE0NTIxNjQwggJbBgkqhkiG9w0BBwagggJMMIICSAIBADCC
AkEGCSqGSIb3DQEHATAoBgoqhkiG9w0BDAEGMBoEFA6JgB8Yl8lWqq9q4lLFsju4
z/qiAgIEAICCAghCSOz2Ky7AUMiDzJKCLHEorDXhiSN+E6/mebeZbifFXp8NHpam
e3UwPIwqaDk7N3AwE7TVzvglht2jTEJvin4PGqewdoQ8g+WWjKG3ynsmoH1ejRuJ
MSqC9TVLfoUUFzvwmi1Ju0uP0+15JTx5hKVY0LANNsOuVO2Y5uOrMotKjE7PkXp/
CdXmG3sW3eJCmmVRq++RHfB1dL57QveHtze+UdArN71sFEkP+Rdl+rAyLePyleyP
5im7B6GwCShuk5/m5P4MdQDhv56rN8Y3tmNY8xjT4Ka7VPCBtilNd4rIHbIPvxa4
fKlTzNWd+ejK1eD4aO9fhntNhdCsTk8Iw2bdhvJ1v2WnS2az0c8atnSrvKxrZkbc
MccqQRNCtD8EHdUmmwP8pXK2oZKU8BnDFkxTWAKf+68v91tY8EHe5N6qxySgWBi5
kBnW41nDYxUhzFSCggUM04oYe5E+wq0QSVQ1jEvtjtBAbwQRkxTzOQX20ivWEGM0
RF4IWqVeXFQlTePGAZBoX0IW+0r7MlB23nmqufEZ+geAsSAypkVlT/1SeMmAHhje
GSSjO1ky3PGk5tE3c+qBNc1rGJv0Z4D07bWNevUhqGInQzrhiCXvRdvL/n9NjWWD
ja7DMXRyS08c1zkxAZy90PecUQI/B3f7yCubNiU0bFbEGDFZHRfcPjCfhsuCypy8
mguMMD0wITAJBgUrDgMCGgUABBQgDu58G+qclCVipEhL46upNrwnogQUdK25NXkz
gkVa/200kVt7Svcg1F8CAgQA


Is "bug banking" occurring? Reading about the fast approaching end of support for Windows XP, I seem to come across a lot of articles which speak about bug banking. Of it being likely that towards the end of 2013 and beginning of 2014, the amount of bugs and vulnerabilities appearing for Windows XP should drop, as hackers begin to stock up on them ready to unleash them once Microsoft drops support.

But... wait a minute. It's 2014 now!

My research can't seem to dredge up any more recent articles on this problem. So I wonder, has it come true? Are there signs of bug banking going on? Is there likely to be a big zero-day assault on XP?

This is largely an opinion-based question, as no one knows for sure, other than the well-informed in underground markets for selling such exploits.
This does make a massive amount of sense, and I wouldn't shrug it off.
Doubtless, there will be zero-day exploits right when support is dropped.
It's probably not as large-scale as some would think, but definitely probable.


Why are Let's Encrypt certificates accepted by default by browsers? I recently almost got caught by a phishing attempt, due to the use of a relatively convincing domain name and valid SSL certificate (specifically this website). When checking the certificate it turns out it was issued by Let's Encrypt. So I went there and as far as I understand the process to issue a certificate is automated - if you own a domain, you can get a certificate.

However isn't it a security issue and doesn't it go (at least partially) against the point of SSL certificates? Malicious websites can now look legitimate thanks to these certificates, which makes it a lot more likely that they will succeed. In my case I saw the green padlock on the URL and thought that all was good. Now it seems, due to this certificate issuer, users will be expected to click on that padlock and check who issued the certificate (and close the tab if it's from letsencrypt??).

So I'm wondering, given the security risk, why do browsers accept this certificate by default? I'm surprised especially that Chrome does given how careful Google is with security. Do they consider that letsencrypt is a good idea?

I think you are misunderstanding what a SSL certificate actually certifies, and what it is designed to protect against.

A standard certificate only certify that the owner of the certificate actually controls the domain in question. So a certificate for g00dbank.com only certifies that the owner controls the g00dbank.com domain. It does not certify that the owner is a bank, that she is good, or that the site is in fact the well known Good Bank Incorporated.

So SSL is not designed to protect against phishing. Just because you see the green lock up in the left corner does not mean that everything is well. You also need to verify that you are on the correct website - that you are on goodbank.com (as opposed to the phishy g00dbank.com) and that goodbank.com is in fact the website of Good Bank Incorporated.

To make this easier for the average user, there is something called Extended Validation (EV) certificates. These also verify that you are the legal entity that you claim to be, by requiring you to do some paperwork. Most major browsers highlight them by displaying the name of the owner in the address bar.

So to get an EV certificate the phishers at g00dbank.com would have to start a real business (thereby leaving a paper trail), and even then they would probably not get one because their name is to close to a sensitive target.

Lets Encrypt does not issue EV certificates. They issue ordinary ones. But the phishers you encountered could have gotten a certificate from anywhere. In fact, as IMSoP points out in comments, the method Lets Encrypt uses is employed by many of the established CA:s as well, the only difference being that Lets Encrypt is more efficient and cheaper. So this has nothing to do with Lets Encrypt specifically, and blocking them would solve nothing.


Port forwarding border router security Few days ago I was asking where to place the OpenVPN Access Server to provide network conectivity to LAN resources for remote users. While looking at the admin guide one of the few options is "One Network Interface on Private Network Behind the Firewall" In this configuration, it is required that the Internet Gateway be set up to forward desired TCP/UDP
port traffic from the public IP to the Access Server‟s private IP address. At a minimum, one TCP
port (typically port 443) needs to be forwarded. I know that ideally it should be placed in a DMZ. The firewall may need to be configured to allow traffic between the Access
Server and the private network behind the firewall. But my question is, what type of security steps should I undertake to make the border router/firewall as secure a possible. I would have to configure port forwarding for port 4443 from the public facing interface to the 1918 IP assigned to that OpenVPN AC, and I know that even though NAT was never meant to provide security it somehow hides my LAN resources, but what else?

I highly appriciate any help.

In an enterprise setting, it is always a good idea to segment the local network so that compromises in one area can't easily spread.

But a VPN solution is particularly tricky to secure since its whole purpose is to take computers outside your security boundary and let them tunnel inside. There is always going to be a risk that you need to be aware of and manage.

Ideally you would make sure that only legitimate devices and users can even get to the VPN end-point, using a non-standard port can be of some help it keeping "casual" botnets at bay. Some form of multi-factor authentication is really a must here.

Also ideally, the inner network that the VPN connects you to would also have limitations and you would certainly want further protected network segments for sensitive services such as your database servers.

For example, you might allow remote users access to some business services such as your Intranet but not others such as your Finance and HR services.

UPDATE: It is quite hard to explain the correct layout in just words. So please reference the SANS secure network design document from their reading room.


How to segregate computers from each other? I have 10 Windows machines in the same network. I want to create two separate groups i.e. machines 1 to 5 in group "work1" and machines 6 to 10 in "work2".

work1 and work2 have the same internet connection. What I need is the work1 machines segregated from the work2 machines. I don't have a dedicated firewall but I have a Linksys rv042 router. How can this be done? On the router level or can any application can do that?

You want to configure separate VLANs on your router.

According to https://www.cisco.com/c/dam/en/us/td/docs/routers/csbr/app_notes/RV0xx_an_vlan_78-21017.pdf, in your routers config this is under "Port
Management > Port Setup". Give the first five a different setting than the other five.


An analysis of storing hints for passwords? What are the security implications of asking users to provide password hints?  What are best practices for storing user hints?  What research has been done on using user-supplied password hints to guide password cracker applications?

Note - it looks like Adobe's astonishing fail with 130 M reversibly-encrypted passwords, stored together with their hints, will spur the field...  Hat tip to XKCD for sharing the news, and the enticing title "greatest crossword puzzle in the history of the world": 1286: Encryptic - explain XKCD

The new GOTCHA method: Generating panOptic Turing Tests to Tell Computers and Humans Apart makes cracking harder, and also brings AI into the field: Inkblot passwords could help increase online security - UPI.com.

The real world impact of hints on security is large. Sarah Palin's account was hacked because someone figured out her high school.

Hints are essentially public info. They are provided to any untrusted person who clicks "I forgot my password." In that context alone, encrypting them doesn't make much sense. But Adobe proved that storing hints with encrypted passwords provides extra weakness.

In general, the security still has to come down to proper hashing of salted passwords. Storing passwords is insecure. Unhashed passwords are insecure. ECB is insecure. None of their mistakes weren't already common public knowledge, and they were all failures to follow best practices.

Would I recommend encrypting hints? Instead, I'd  recommend they use an out-of-band password reset process (via SMS or some other method) and skip the hints entirely.


How to securely ask for additional PII / account verification? Since it's a bad practice to ask users to click on a URL within an email to verify their identity due to phishing concerns, what is the best way to ask a user that additional PII information is necessary?

The following example from Stripe.com is asking for an email address, and a subsequent URL to click on.

Aside from emailing the end user, what other channels are best for requesting this information?

If email is the only choice, what is the best approach to ensure that the user will indeed click on the link and proceed with the verification.  Our goal is to limit abandoned carts in the event the user doesn't see or ignores this request.

This kind of scenario essentially features a trade-off between usuability and security, and which option you decide to go for will depend on the risk appetite of your organisation.

Ideally from a security perspective you should not encourage users to click links in e-mail given the lack of reliability of e-mail and the prevalance of phishing scams which involve getting users to click on links in mails.

So the best option from that perspective would be to send a mail to the customer (or contact them via another channel if they've provided those contact details) and ask them to go to the site themselves in the browser, log in and go from there.

Of course this isn't a great user experience and that's why a lot of companies choose to put links in e-mail for people to click.  So if you do do that, some things to consider

Try to avoid using 3rd party click tracking sites, so at least the user is going to your domain and can verify that assuming they know what to look for of course.
Consider digitally signing your e-mails.  Again I'm sure a lot of users won't notice but it helps for those who are more security aware to have some extra confidence that the mail is legitimate.


VPN using SmartPhone Location When establishing a VPN connection using a hotspot, can the VPN provider identify the location from which you established the VPN connection?

I think the answer to that is 'it depends' - I was looking at something similar recently, for example the IPs issued to the AT&T phones we tested all resolved to an Atlanta, GA address - even though none of the devices were within a few hundred miles of Atlanta.

Different carriers are likely to yield different results though - some may yield more accurate results than others.

Trying to tie an IP to a physical location is often unreliable, it depends on the service provider to provide more detailed information about smaller IP blocks than they typically do. It's that much more management overhead.

I never assume that the location mapped to an IP address is correct.


Is it safe to store and replay user-provided mime types? If a user uploads a file but modifies the request by setting the mime-type to something arbitrary, like "superdangerous/blackhatstuff", is it safe for me to send the same mime type back to a different user later on?

I.e. another user downloads the same file and I set the mimetype to "superdangerous/blackhatstuff", is it possible to set the mime type to something potentially dangerous? Because it is user-supplied data, I get the feeling it's not a good idea to store and replay without some kind of sanitization. (I am of course, sanitizing the query before I store the mime type, so I'm not concerned with SQL injection attacks via the mime type.)

I am using clam AV to scan uploaded files, which hopefully catches some of the mime sniffing attacks, but that's not really what I'm asking about here.

If this is, in fact, dangerous, then what is the proper thing to do? Should I not specify a mime-type at all, and let the receiver guess it? Should I try to do my own mime sniffing (I'm using PHP on Linux, which provides an API for file magic.)

Edit: More Details

Let me explain the purpose of this feature. The application in question is used as part of a workflow that requires various kinds of artifacts to be submitted for review and approval, including (but not limited to), word docs, spreadsheets, images, and archives. Other users will need to be able to download these artifacts in order to view them and make an approval decision.

To prevent the some obvious breaches, we have blacklisting in place  (such as uploading a PHP or Javascript file) and we are setting the Content-Disposition to "attachment; filename=...". We are running Clam AV on uploaded files as a basic sanitization, since we can't really enforce a whitelist on our users. The app runs on an intranet and requires authentication before anything can be accessed, and our users are [mostly] trusted.

Anyway, point being is that I'm not asking about the safety of storing files and letting users download those files. (I realize it's a large threat vector, but it's not the question I'm asking.) I'm really more concerned about whether it's safe to replay a user-supplied mime-type, and if not, what is the alternative? To not specify a mime type at all?

No, you shouldn't reply the user-supplied MIME type to the user. The simplest attack that you're exposing your users to would be to upload text/html file with arbitrary Javascript code e.g. in [script] elements. Users given the uploaded file URL would have the Javascript executed, resulting in XSS. This can be somewhat mitigated by serving the files with Content-Type-Disposition: attachment header, but there are ways around that.

Another vector would be storing malicious Java applets or Flash files and many other files whose MIME type make them relevant to web security (HTML5 offline manifest file, crossdomain.xml, various files executable on client - exe, vbs, ...).

While we're at it - be sure to serve the user-supplied files from a domain separate from your 'main' applications, to protect from XSS attacks (same origin policy will stop them if files come from a different domain).


How does add-on for the Firefox with a custom proxy server prevents info from Google? I would like to know how does add-on for the Firefox web browser with a custom proxy server prevent Google from collecting information about your browsing?
Does it prevent also from your internet provider to collect information about you as well as your location?
Are there any other ways to keep your privacy from your internet provider as well as Google?

Google sharing worked as a "search exchange".

You'd offer your computer as a restricted proxy (only for google) for other users, and use proxies of other users who did the same for your searches.

The main trick was the use of https - SSL sessions were still maintained by your computer and you could still verify google certificate - only the raw tcp session were proxied.

That way users still kept their searches confidential. Sadly google cracked down on this (because it was used by bots for automated searches) - quality of service degraded to that of google behind Tor, meaning a LOT of captcha, and mandatory cookies for all "exit IPs" - effectively all users in of the google sharing IP anonymity set. Instead of fixing this, moxie discontinued the service.

I'm currently in the middle of reviving the concept, with tit-for-tat (search-for-search) implementation, so that bots can't ruin the service again.

EDIT: As per request expanding the answer. Just to clear up how it exactly worked, the life cycle of each request went like:

searchclient's http_POST-> tunnel server <-http_GET_longpoll proxyclient->google

The HTTP POST / GET pair serve just as mere TCP tunnel (the tunnel server was written in python with twisted and they were federated IIRC).

What alternative is there at the moment? Just use Tor. You'll have to fill captcha now and then, and google will keep track of your search session (ie they could group searches together as belonging to one person), but they can't identify who it is. If you drop breadcrumbs through searches, switch identity in tor browser every time you do.

As for the proposed reincarnation of google sharing, the idea is to run some sort of overlay P2P network (no more tunnel server as an entry hop to proxy) - we have WebRTC these days - it didn't exist in 2010.

The tit for tat mechanism to prevent bots works on proxied data usage (because you can't guess how many searches were done over ssl, only the amount of results). The proxies will talk one to another similiar to how bittorrent works - they'll be reluctant to proxy for somebody who didn't proxy for us first, with some random altruism to bootstrap the exchange.

This "karma" could be also delegated from common friends, so one is not restricted only to peers being proxied for in the past.

The peers generally knowing each other isn't perceived as a problem as it would be in Tor, because nature of this traffic would be to switch proxy per every search. At best an adversary could uncloak one or two of our searches, but not most. In the original Moxie's design, the intermediate servers could uncloak all clients, assuming google would be complicit adversary. This was deemed inpractical (and still probably is), as google would have to log packetdumps of all SSL traffic they get, so they could cross check with packet captures from tunnel server.

The advantage of exchange compared to Tor is mainly having comfort of search near to that of direct connection (assuming your upload bandwidth can accomodate the tit-for-tat exchange) and being less suspicious overall as anything originating from Tor or even well known VPN services is sure under heavy scrutiny.

Ordinary user IPs is a drop in the ocean.


Can I determine a private key given the encrypted data and corresponding cleartext? If I know that Data A is an encrypted form of Data B is that sufficient information to determine the private key?

If the key can be recovered from knowing both a plaintext and the corresponding ciphertext, then this is called a known plaintext attack; an extension is the chosen plaintext attack where the attacker not only knows the plaintext, but gets to choose it. If a cryptographic algorithm is subject to CPA, then it is considered weak and broken. Thus, a secure encryption algorithm MUST resist CPA (and therefore KPA too).

Note that with asymmetric encryption (RSA), since the public key is public, everybody can create millions of plaintext/ciphertext pairs. This illustrates that an asymmetric encryption algorithm could never have been considered secure if it was broken through CPA. Conversely, it was long assumed that with symmetric encryption, the CPA model was not scary, because the attacker cannot encrypt data of his own without knowing the key; practice proved that theory to be wrong (in the case of HTTPS, evil Javascript or even plain HTML can make your browser issue requests with contents at least partially chosen by the attacker).


Does GOOD Dynamics Proxy comply with EU data legislation? My client is excited about GOOD technology; it allows them to have controlled access to  business applications & email from BYOD (bring your own devices) and will enable a more mobile workforce.  Another department within the company has installed GOOD and allows access to email and some whitelisted web apps.

Whilst testing the GOOD browser, we didn't recognise the exit node IP address from the GOOD Browser and it turned out to be some infrastructure hoster that we did not recognise.  It turns out that all traffic from the GOOD apps is routed through various proxy servers at GOOD's "Network operations Centre" which itself is hosted on various cloud providers.  One would "expect" that the browser would directly access the website — but it doesn't.

  The risk is that GOOD themselves, or their cloud suppliers have unencrypted access to all the traffic.

Given that many EU financial organisations use GOOD, how did you get compliance?

do you include GOOD as a data processor?
do you allow users to use this for any classification of data?
or do you restrict the usage?

I am not sure what the concern is here. Presumably you currently use a mail provider that you send unencrypted mail through.

Or if it is sensitive mail, you'll encrypt before you send it, right?

Using Good, you'll be doing the same, but you will have some additional protection for the device itself, and some segregation of your corporate mail from the user's personal mail (ie no copy and pasting from corp email to their own one)

It also allows you to restrict access to applications - allowing users to use their own device to connect, rather than a corporate device. If your data is sensitive you may encrypt end to end anyway, but in any case you'll have a contract with the provider to detail what their responsibilities are.

As regards compliance, where a regulator asks you for your compliance information, those aspects you have outsourced are still within remit, so you need to be able to answer them. The only ways to do this are by requesting this information from the 3rd party or by auditing them.


Can be used ECDH with static public key and parameters? I have protocol required for privacy. Thus, I want to use hybrid cryptography. Base on my knowledge, ECDH is fast and secure.
My system consists of 3 main components a trusted-server, client, and server

1- The server will generate ECDH parameters and the private key
and compute the public key.
These parameters and the public key save at the trusted server.
2- When the client joins the network, the trusted server sends the
parameter and public key to the client.
3- The client generates his private key, computes public key and then computes
the secret key by using the public key of the server that was received
from the trusted server.
4- The client encrypts his message by using the secret key and
send the encrypted message and his public key to the server.
5- When the server receives the message, the server computes the
secret key by using the public key of the client and decrypts the
message by using the secret key.

My questions are:
1- Does this scenario is correct?
2- Can be used ECDH with static public key and parameters?

The scenario does not seem correct; what's to stop an attacker man-in-the-middle'ing Step 2?

I don't see any way in your protocol for the client to know that it is talking to the real trusted server and not an attacker.

I also notice that your solution provides no way to block a client from joining the network and/or verify the identity of a client prior to letting them in (ie it provides privacy but no authentication). Doing that would require bootstrapping your clients with some sort of certificate / pre-shared key / auth token prior to it joining the network.

Basically, your clients will be communicating security with someone, but they will have absolutely no idea who. When you allow attackers to join the network freely, then what's the point of encryption?

Static ECDH does exist, so you can use it but I personally have never seen it used "in the real world" it's always ECDHE+RSA using a RSA certificate from a CA, or something similar.

Yeah, basically don't invent your own crypto protocol. Just don't.

There are any number of secure networking protocols with open-source implementations that have been well designed by crypto experts. Signal / libsignal comes to mind, though there are many many others. This is a solved problem, don't re-invent the wheel.


Role Based Authorization vs. Claim Based Authorization What is the difference between "role based authorization" and "claim based authorization"?  Under which circumstances would it be appropriate to implement each of these authorization models?

Claims are a method of providing information about a user, and roles are a description of a user by way of which roles they belong.

Claims are generally more useful because they can contain arbitrary data -- including role membership information. E.g. whatever is useful for the given application.

Claim Based identities are more useful, but tend to be trickier to use because there's a lot of setup involved for acquiring the claims in the first place. RBAC identities are less useful because they are just a collection of roles, but they are generally easier to setup.

The .NET stack, and Windows as a whole, is going claims. Windows authn tickets are claims, and Active Directory now has the ability to use claims for certain functions. The .NET stack uses a claims identity as the base identity object now by default.


Verify TLS intermediate certificate In the answer to question "How TLS certificate chain is verified" it mentions that the involved intermediate certificates are "fetched and validated". How exactly is that done?

Specifically:

So I know the intermediate certificates can be stored locally at a client or served by the server. Are these two sources trusted the same? Do you have to fetch the intermediate from a server that is owned and operated by root CA or signing CA?
When a intermediate certificate is verified, does the client connect to the domain of the intermediate certificate owner to validate the certificate against the live domain? Or would a local-only algorithm do all the work up till the root certificate?

The system that is verifying the certificate chain has a local store of root CA certificates. The private keys associated with these certificates are used to sign intermediate certificates. The private keys for the intermediaries are then used in turn to sign certificates that are issued to servers. When obtaining the certificate chain from a server (the full chain can be requested from a properly configured service) this chain is walked, verifying signatures up the chain, all the way to a root CA that is in the systems local store.

If an intermediary cert was forged then the signature from the root CA that signed it (contained in the intermediary cert) would be invalid and the chain would be broken.


What is the best way to screen potentially compromised USB or flash devices? I've got some flash devices. It is a bit like playing Russian roulette. The devices are of unknown origin containing information of unknown value. However, the potential value is great enough to be worth the effort to recover and exfiltrate the data to a secure network.

There is a high degree of risk the devices maybe loaded with malicious firmware but the risk of bad firmware is acceptable if the information proves valuable.

However, the issue still remains - what is the best way to screen high risk flash devices and bring valuable information to the secure network from one or more of the devices - including a compromised device - while ensuring the malware doesn't get introduced to the secure system.

Assume the malware is custom and unlikely to be identified by virus definitions.

Edit:
I have more than one computer and access to live images. The hard drives are fully encrypted.

Start with an optically isolated USB Hub: http://www.sealevel.com/store/hub7i-optically-isolated-7-port-usb-hub.html to protect against USB Killer.

Then you want a machine that malware is unlikely to target: Maybe a Sparc box running NetBSD? If the attacker is truly targeting you, this won't help, but if they are limited in their knowledge or effort it might protect you against driver/OS/firmware attacks.

Then you need to sanitise the data - hopefully plain text is sufficient - convert the data into plain .txt (stripping all the formatting).

Then write the plain text to a different USB stick/CD and it should be safe to use on your normal machines.

The only further risk is that the information is crafted to be convincing but false. (An attack on the wetware :-) )


Make nginx drop requests to timeout client on purpose I want to avoid nginx from processing requests and hiding the fact that it even exists at a certain IP by not answering at all. The requests should be dropped and the client's browser should time out on it's own. Is that possible?

My guess is that a proxy_pass could help, but I'm not sure if that alone will do it.

I could configure a return 50x;, but that would reveal a server running.

Make nginx drop requests to timeout client on purpose

It is not possible to drop HTTP requests to hide the server, no matter if using nginx or another server. The HTTP request will only be sent after establishing the TCP connection. This connection can then only be closed with or without a response. You could also keep it open so that the browser times out but each open connections needs resources at the server.

You can only hide the server for clients based on the source IP, not on the contents of the HTTP request (i.e. specific URL). But this would not be done in the webserver but in the firewall (i.e. iptables, ipfw, pf or whatever you have).

if your intend is to annoy the typical bots testing for possible exploits then you might try it with a redirect to a nonexisting IP or port. Any access to this port could then be dropped by the firewall so that the bot runs into a timeout. I do this on my site and in my experience this will slow down bots because most  will happily follow such redirects.


Could a fake tip that my server is compromised be a social engineering attack? A little while ago I got the following email from an unknown party (using an @alum.cs.[redacted].edu email address):

  I'm seeing attack traffic from your Linode. Just a friendly heads up that its likely p0wned. A quick google suggests no one else likes the traffic coming from your Linode either.
  <https://www.google.com/search?q=[my Linode's IP]>

However I couldn't find any evidence to support this assertion. I checked the resource utilization graphs provided by Linode, as well as my firewall logs, system's process list, active connections, recently modified files, user accounts, and so on, and found absolutely no anomalies. The results from the Google search didn't seem to back up the claim that nobody else likes the traffic either; nothing I saw in the first few results raised any red flags. So either the server is fine, or I'm dealing with an adversary who knows how to cover their tracks so well that I can't imagine why they would have any interest in my Linode. (There is no sensitive data on it.)

This leads me to wonder whether the message could have been a form of phishing. In this particular case, I doubt it, but could something like this be a legitimate social engineering tactic? Is there something I would be likely to reveal by replying to this message which could be used against me in some way I can't think of?

If and when this happens in the future, my goal is to respond in a way that allows me to collect the information I need to track down the attack in case it is real, while not revealing anything too compromising in case it isn't real.

The message itself isn't phishing, but it could be the first stage of a social engineering attack.

The message (that you quoted) isn't asking you to do anything specific, so it is benign. But, if you reply asking for further details, they might ask you to do something specific (run a program, log into their service, etc.), which would be an attack.

Otherwise, the person could be confused. I see no harm in replying and seeing what the next step is.


FIPS Compliance for my Android project I am working on a security-related project and have to make sure it is FIPS 140-2 compliant.

According to my understanding, FIPS compliance is compliance at hardware as well as software level. Currently there are 2 Samsung Android devices which are FIPS compliant, i.e. they have compliance at hardware and software level.
I have a few questions.

If I want to make my Android app FIPS compliant, if the only crypto module used in my project is compliant, is it enough?

The crypto module provided by the Android SDK is the BouncyCastle library and it is not FIPS compliant.

I am using the FIPS-compliant OpenSSL library in my project as per https://stackoverflow.com/questions/11091905/android-build-openssl-fips-2-0. I have built my project library using the OpenSSL library ie libssl.a and libcrypto.a configured using FIPS mode.
According to the the FIPS OpenSSL module for Android documentation, the module has been tested on different Android devices of armv7 architecture. Will Android hardware not being FIPS compliant matter here ?
AES algorithm is under FIPS compliance. Does this mean that if I use the AES algorithm in Java code instead of using the FIPS-compliant OpenSSL library, it isn't FIPS compliant?

If AES is under FIPS compliance, what does it have to do with a Java or C# implementation of AES. Do they both have to pass through the CMVP?

By FIPS, I assume you mean FIPS 140.

FIPS 140 defines four levels of security.

Level 1 is essentially about implementing cryptography and authentication correctly, as in passing some basic functional tests. You must use approved algorithms for cryptography and for random number generation. You can certify a software product at level 1.
Levels 2 and above involve gradually stronger security mechanisms. The hardware must be included in the certification.

Do not confuse FIPS 140-2 (“fips one-forty dash two”), where 2 is the version number of the standard, with FIPS 140-2 level 1 (“fips one-forty dash two level 1”), where 1 is the level of security.

You'll be wanting FIPS 140 level 1 then.

Regarding your question 3: FIPS 140 requires a validated implementation, and you can only validate an implementation of an approved algorithm. AES (with a suitable mode) is an approved algorithm, it's up to you to have the implentation validated. Note that in order for your software to be FIPS compliant, you don't just have to follow the standard and say it is compliant: you need to go through the validation program.

Using a validated crypto library won't help you much, except perhaps for the random number generator. You'll have to select approved algorithms, and pass the comformance tests anyway.

FIPS 140 level 1 isn't much more than what you'd do in a serious product regardless of certification (use reasonable algorithms, run a few tests). It does add two requirements for which a FIPS-compliant library may help a little:

Each algorithm must be tested before use, after each power up. Testing means running one test vector and verifying the result. Your software must refuse to use the algorithm if the corresponding test has failed.
Any key that is stored in your module must be erased after use. There is no strong security validation here, but you may run into difficulties if you're using a language with a garbage collectors that can move objects around.

If you use a FIPS-compliant library, it's possible that your client will be satisfied with that and won't require you to validate your software. You have to take it up with your client.


Are EV certificates still useful? Years ago (~2010-2019) the Extended Validation (EV) Certificates made a lot of sense.
The user in their browser would see a clear difference between

a "grey" (http/not secured) website
a "green lock" (https normal certificate) website
and a "green lock with name of the company owning the website" (https ev certificate) website.

Back then having such a certificate meant that normal users would have a clear indication they are actually connected to the website they had in mind.
Today (~2021) in Chrome I no longer clearly "in your face" see the difference anymore between a website with a normal certificate (like my homepage) and a website with one. Knowing their existence I actually had a hard time finding a website that still has one.
So my question is in general: If there still any value for any website to have an EV certificate?

If there still any value for any website to have an EV certificate?

Effectively, no, since most browsers now treat them the same as non-EV certificates.

Since fall 2019, the green bar and company information has been
removed from all major browsers, such as Google Chrome, Mozilla
Firefox, and Microsoft Edge (with Apple’s Safari browser having
removed these indicators even earlier). (ssls.com)

If the difference isn't presented to the user, is there really a difference?
As you've shown, there is more information presented when you click through to an EV certificate, but how often will an end user click through?  How many end users will understand that seeing the company name there implies anything different about the trust level of the certificate?  The decision to bury this information has devalued it, and we will see less sites investing in an EV certificate as a result.


How does a digital certificate prevent impersonation by holding other's certificate? As far as I know, a digital certificate  contains information about a user or firm that has been vouched for by a trusted organization.

https://www.geeksforgeeks.org/digital-signatures-certificates/ says

  Digital certificate is a file that ensures holder’s identity and provides security.

If person A holds the digital certificate of person B, can A impersonate B?

How does a digital certificate prevent impersonation by holding other's certificate?
 For example, when using certificates to authenticate a web server, how can a digital certificate prevent it from impersonating another web server by holding the other's certificate?

Thanks.

No.  Possession of the certificate alone is not enough to authenticate a user.  The user must also have possession of the private key corresponding with the public key in the certificate, and must complete some cryptographic operation using that private key, to prove that they have possession of the private key.  See Could a stolen certificate show as trusted? for more information.


Limiting a CA to only issue valid certificates to internal web sites and clients What are the possible defense measures that can be applied to a simple PKI  (no intermediate CAs, etc.) used to authenticate clients and servers over TLS on an internal network only?

Certificates issued to clients/servers will have to appropriate TLS Authentication extended key usage set.

Since the CA will be trusted on all devices, I want to make sure that even if the our CA's private key is compromised, the attacker wouldn't be able to create certificates for Internet web sites, or to create trusted signed binaries. In other words, I try to minimize the vulnerabilities that are opened up by the authentication scheme.
Is this possible using X.509 constraints?

So far I've thought of setting the pathLenConstraint to 0, and using the nameConstraints so only certificates issued to private IP addresses should be accepted.

It seems that these measures prevent a lot of misuse, but they still allow the attacker to issue a certificate for e.g. google.com, then—using MITM—impersonate the DNS server and reply with an internal IP address (pathLenConstraint ✓, nameConstraints ✓, intended usage ✘). This scenario would even work with nameConstraints set to the local DNS suffix, since most clients just send another query with the suffix included, if the response is "not found."
Not to mention that I've found no way to prevent a CA (using X.509 constraints) to ever issue certificates used for code signing or timestamping.

Is there any option that I've missed?

the only defense against this is using Key Pinning

the problem is that that only works as soon as the client has connected with the web service at least once (to have the proper value for the pin)

and another problem can be that the pin holds for a long time so replacing your certificate or key is not possible while the pin holds (unless you plan ahead and and have a second certificate already pined  for the crossover)

After your edit I must conclude that at present there is no way limit such use. there is no solid way to limit a CA certificate to just 1 part of the network. (it's policies that do this. not a technical implementation)


Reason to use only secrets as API keys? Many APIs protected with API keys only use the secret key (i.e. a password) without something like an account ID or username.

For example Stripe API uses the secret key as the username in Basic Auth, leaving the password blank:

curl https://api.stripe.com/v1/charges \
   -u sk_test_BQokikJOvBiI2HOWgH4olfQ2:

How does this work server-side? Does it look for the secret in a table with the secrets as primary keys, in plain text? What happens if this table is leaked?

Why is this better than to use a account_id:secret_key combo in the authentication? You can then store bcrypt(secret_key) instead of the secret_key in plain text, using the account_id as the primary key.

Related, but not the same

Those API keys are often called tokens. They are often assumed to have a rather short lifetime and are more or less used as a high level session id. It is not a true session because they are used for stateless requests and only carry user identification. But their lifetime generally spans from a few hours to several days. More, they are never a primary access key, so if the token database get compromissed, it is immediately emptied and users ask for new API keys.


GEA3 direction clarification GEA3 (and 4) stands for GPRS Encryption Algorithm. It's specified in 3GPP TS 55.216 (at least used to, until some idiot forced them to hide it because of "export restrictions" or some crap like that). One of the parameters for generating gamma using GEA3 is 1-bit "direction" value which represents either MS to SGSN (or opposite) traffic. Surprisingly none of the specs I've seen says explicitly which value corresponds to which direction. So, what exactly is direction 0 and what is 1 in GEA3 and GEA4?

Doh! The MS -> SGSN is 0, SGSN -> MS is 1: they have put it into appendix - probably just to make it easier to find.


Is there a safe way to upload a malware into a centralized server? I'm facing an issue which i need to upload files to a centralized server, then relay it to other malware analysis providers (Palo Alto / etc...)

As from security perspective - it's forbidden for the file to reside in the server's file system and memory.

The server is ASP.NET based, and the client is C++ and i thought about streaming (currently we stream those files through IIS) - but i have some major drawbacks:

I think that IIS can cache data it receives, meaning - i have no control on the data flow (malware can suddenly reside in IIS memory).
Even if i use TCP components - who said that there's no caching in the server side? I would hate to write the entire TCP handling myself (which never will be efficient like the already written ones)
Other option i was thinking is to XOR the files, but if i do it on agent - compromised machine can manipulate it and send the original malware, and in server again, it could be that the malware is already cached in memory.

In addition to #3, XOR, or any password protected zip files methods (that client can send) are no acceptable aswell, as exploits might be used to decrypt this file in the server and run it (though those are slim chances).

The 3rd parties we use also expect the original file's data.

The only "acceptable" solution is to sandbox the receiving process with its files, either by a 2nd server (which is not acceptable by our on-premise customers) or in our "real" server (some kind of container - which seems like a super overkill)

Would love to hear your comments about this?

Just ZIP the file with a strong AES password or use OpenPGP or Minlock file encryption (on the client before upload).

This protects your server from accidental execution, it hides the content from scanners, it will also protect integrity and will protect the analysts from accidental exposure on/after download. In fact it's the only reliable method to avoid accidental corruption by intermediates anyway. I don't think any forensic company accepts files without packing them in containers.

Yes you stated you don't want to ZiP, but you have not mentioned convincing reason why not: The threat model 'might be decrypted and run on server' is not valid, if an attacker can generate files and execute them they don't need your encrypted content to start with.

Using streaming adds very much distribution logistic as all receivers have to know and be online at the same time. And even with streaming you want to package, encrypt and integrity protect your network transfers.


What measures must be taken to securely authenticate from web traffic to a WebSocket connection? Obviously TLS is a must for any and all secure authentication.  Please turn your paranoia settings up to 11 for this.

Background: (In case people are unfamiliar with the WebSocket (WS) protocol and its idiosyncrasies) The WebSocket TLS (WSS) connection is a different connection from the HTTP TLS connection.  This means that one can not automatically authenticate the other.  Because of proxies, especially a malicious one performing a MitM attack, simply having the same remote IP address (or even the same session ID) does not guarantee that the two connections are from the same browser.

WS is a persistent TCP connection with a very limited API on the client side that does not allow inspecting of the TLS details for a WSS connections.  It is designed to play well with firewalls and (non-malicious) proxies that restrict traffic to just HTTP traffic, and is desireable due to its ubiquity in modern web browsers.

In PHP, WS is (typically) implemented using a command line (CLI) script, which runs its own server accepting and managing the socket connections directly, rather than being mediated through an HTTP server.  (If an HTTP server is involved, it is only to forward traffic after the successful upgrade, and becomes a transparent proxy for all purposes after the handshake.)  Thus, the typical PHP superglobals are meaningless in PHP CLI.

Passing cookies is possible during the WS handshake, including a session ID.  In PHP CLI it is possible (but ungainly) to access the current session data, even after a state change triggered by the HTTP side of things, if you know the session ID.  However, because the cookies are passed only during the WS handshake, the WS server does not get notified of changes to cookies, such as the session ID.

AJAX remains authenticated through the HTTPS connection, of course, and I'm sure there's a way to leverage AJAX requests to authenticate WSS connections using the same browser.

Example Session Hijacking: Alice logs on to bob.com via normal HTTPS means, but happens to have a malicious proxy between them, owned by Mallory, running a MitM eavesdropping attack that has compromised the session ID.

Mallory then uses the session ID in his own session cookie to connect to the WSS server, which is where I run into my issues, because I don't know who to then differentiate between Alice's open and fully-authenticated browser and Mallory's completely different browser on a completely different computer.

So, knowing that the session ID is potentially insecure, is a prime target, and is immutable once the WS connection is initiated, how can I authenticate that a given WSS connection is running in the same browser instance on the same computer as a given HTTPS connection?

Edit: Once the HTTPS connection is started, Mallory does not attempt to interfere in order to prevent being detected. Thus, once TLS is established, the HTTPS connection is secure from Mallory from this point forward, but Mallory would have the session ID still.

Justification for this edge-case requirement: I'm writing open source WebSocket software, thus am unable to enforce protecting the session ID through means such as ensuring the session cookie has the Secure flag set, that the session ID gets regenerated, etc., but can enforce having the implementer include a client script that would aid in ensuring authentication across both mediums.

The WebSocket TLS (WSS) connection is a different connection from the HTTP TLS connection.

A WebSocket connection is created sending a HTTP request containing the wish to upgrade the connection to WebSocket and by receiving a HTTP response granting this wish. From then on the WebSocket protocol is spoken inside the upgraded HTTP connection.

This means that the common security properties of HTTP are still usable with WS, i.e.  things like basic authentication or verifying the identity of the peer against a session cookie given by a previous login.

It also means that the security properties of TLS can be used as with normal HTTPS connections. Like HTTPS, which is HTTP spoken inside a TLS connection, WSS is WS inside a TLS connection. This also means that preventing man-in-the-middle attacks by validating the certificates is done exactly the same way as with HTTPS, because every WSS connections starts as HTTPS connection.

If I understand you right you consider that Mallory manages a man-in-the-middle attack against the connection at least once. If Mallory is able to do this he must be able to man-in-the-middle the TLS connection and in this case game over is anyway, no matter if WebSockets are used or not. If Mallory is instead gaining the information from a non-TLS connection (i.e. HTTP not HTTPS) than you have a design bug in your application if you use unprotected authorization data for authorization inside secured connections, no matter if HTTPS or WSS. And no TLS or other methods can make compromised authorization information magically safe to use again.


Are there risks associated with connecting to a public hotspot? When connecting to a unknown public hotspot, I know that the data transmitted can be captured and, if unencrypted, easily analyzed. But that's not the question here.

I want to know whether the information saved on the computers (company computers running Windows 7 - 8 or some Linux installations, some smartphones, Androids and iPhones), which is not being transmitted, is also at risk? Can a computer be cracked just because it's connected to the hotspot?

If the answer is yes, what would be an appropriate security policy to deal with it? Prohibiting connecting would be a more extreme measure, is there anything else?

As long as the user connects as a public network, there isn't any more connection connecting to an open WiFi network than there is connecting to an unknown wired connection.  If the user says it is a private or work network, then a lot more issues can occur.

Ultimately, it is the job of a firewall to prevent access to a system when it is attached to a network and a well configured firewall should prevent an issue when attaching.  Exactly how you handle that configuration is significantly more complicated.

The trick comes down to what services the computer makes available when connecting to a network.  Services like remote desktop, file and printer sharing, telnet, or whatever services might be on the system may be running.  If they are, then any system that can connect to the computer will be able to try to access them.

Disabling those services or firewalling the system prevents that, but you need to make sure you don't block necessary services while dealing with the unwanted services.


Firefox: certificate can’t be installed I would like to run an https C++ server from this source code.

I have followed up this website to generate the certificate:

openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

which led to creation of four files:

server.crt
server.csr
server.key
server.key.org

Then, in my firefox browser, I go to preferences/advanced:

about:preferences#advanced

Then view certificate, your certificates, import.

But at the end, I face with an error and nothing happens:

  This personal certificate can’t be installed because you do not own the corresponding private key which was created when the certificate was requested.

All necessary file including server.key are there.

What is the problem?

What should I do?

It looks like that Firefox (and Chrome too) can only import key and cert together if they are inside a PKCS#12 file but not when they are in a PEM format. To create such a file from the created certificates:

openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12

Then import the server.p12 file in Firefox.


Verifying Client with Server I'm currently designing a basic Java program that uses sockets to communicate from a server to multiple clients. I want the clients to be unmodified, however, to prevent against users trying to use the software not how it was intended. I'm considering using an MD5 checksum and sending it to the server to compare it with what the checksum should be, but a modified client could simply send an incorrect checksum to fake the server into thinking that the client is untouched.

To put it simply, how would I go about verifying a client in such a way, that a modified client cannot fake being unmodified?

IF what you ask was possible, THEN there would be no software or video piracy whatsoever. You could have some playing software that simply plays the movie but refuses to dump the data in a file, and that playing software would "prove" its unmodified status to the server, thus allowing the download.

This tells us that what you seek must be hard and would be worth an awful lot of money if it was ever invented. There also are good theoretical reasons why it is actually impossible, which would explain why nobody found such a way to reliably validate software remotely. The bottom-line is that you cannot ensure integrity of anything that runs on the attacker's own machine.

Now, if you have some high level of control on the target hardware, then things become possible. This is the security model of existing game consoles: the firmware and all games are under strict control of the publishers; no new software enters a console if it has not been digitally signed by an allowed publisher. Mere users cannot simply program their console. This is still hard to do properly -- console firmware, like any software, has bugs and thus all this signature-based shielding might be worked around occasionally -- but at least it can theoretically work.

But for a PC, forget it.


Is BitLocker on a virtual machine FIPS 140-2 security level 1 compliant? BitLocker can be used as a cryptographic module to fulfill FIPS 140-2 security level 1 compliance.

What if the encrypted drive is on a virtual machine, is that still FIPS 140-2 compliant?

In one BitLocker virtual machine setup, one of the drives or volumes on the virtual machines' host can acts as a cryptographic key provider to hold the cryptographic key.

The only problem is that this kind of seems like BitLocker implementation mostly subverts the protection that BitLocker is providing in the first place.

In the article entitled "BitLocker Drive Encryption in Windows 7: Frequently Asked Questions" microsoft states that they do not support the use of BitLocker on a virtual machine.

  Can I use BitLocker within a virtual machine operating environment?

  BitLocker is not supported for use within a virtual machine. Do not
  run BitLocker Drive Encryption within a virtual machine. You can use
  BitLocker in the virtual machine management operating system to
  protect volumes that contain configuration files, virtual hard disks,
  and snapshots.

But what does this mean for FIPS 140-2 compliance and a virtual machine?

If Microsoft does not support it, is BitLocker still FIPS 140-2 compliant in a virtual machine?

There's an interesting discussion on this topic.  I would agree with this assessment that a virtual drive holding the encryption key would not qualify as FIPS 140-2 compliant.

  In the security policy, §2.3 describes the platforms on which the certification applies: it lists several versions of Windows, with no reference to any particular hardware. Then §6 describes usage requirements that must be met in order for the certificate to apply. One of the FIPS-compliant startup mechanisms listed in §5.2 must be in use, therefore the machine must have a PIN pad, a USB connection or a TPM. The policy does not explicitly describe the connection between the machine running Windows and these peripherals, therefore a virtual machine would be acceptable.

  A virtual thumb drive would be a different matter. As there is no actual USB involved, I don't think the language can be construed to cover this case.

That said, CREDANT Manager for BitLocker make a BitLocker encrypted drive on a virtual machine comply with FIPS 140-2.

  CREDANT Manager for BitLocker forms part of a single, central management solution which helps ... offer an integrated approach to managing encryption across other, non-BitLocker platforms; physical, virtual and Cloud-based.

  ... the encryption management solution provides simple, centrally managed key recovery and is FIPS 140-2 validated.

I suspect there are other central key management solutions.  CREDANT was just the first one I found.


Can botnets be injected through open wifi to smartphones? I have read this paper, which is answers part of the question. It answers, 'open wifi will help increase the spread speed and impact' but what I want to know is, can you 'plant' an open wifi access point/router and when any smartphone connects, it will be injected with botnet/malicious code ? Disregarding OS.

Barring an exploit in the drivers on a device, a smartphone would have to actually access some online service that could be compromised.  The main risk with a rogue open wifi hotspot is that when SSL encryption is not used, the rogue network can replace the responses from requests to legitimate web sites and services with its own attempts at attacks.

The user would still have to access a service on the network (or have some service configured on their phone to automatically be accessed) and an exploit would have to be returned that is able to compromise the phone.  This would generally be relatively difficult if a device is patched up to date, though may be a bigger risk if running outdated software.

It would take a rather complex attack to be able to try to compromise a large number of devices running different OSes and configurations as the services that would be called the the exploits that might allow access to take over the devices would be very different.

The only real advantage a rogue AP gives over any other attack on the Internet is that they can replace non-SSL (or otherwise authenticated and encrypted) protected calls to web sites and services with their own response.  This only simplifies getting someone to access a compromised site though, it doesn't allow anything that couldn't be accomplished through a compromised link such as what might be found in a phishing e-mail.

It's also worth pointing out that the article you linked simply points out that open wireless networks can be used as an effective network connection for controlling a mobile botnet.  It doesn't have anything to do with creating infections, just establishing that communication can be done reliably and that it makes detection of the bot nets operation through traffic analysis difficult.