similar to: How does SMB 3.0 encryption work?

It does, thanks. So if the password is known, or the KDC compromised, then in principle MITM becomes possible? On 2017-08-14 15:28, Andrew Bartlett wrote: > On Mon, 2017-08-14 at 06:45 -0400, Daniel Benoy via samba wrote: >> Is it perhaps using your password somehow? Like, if an attacker knew >> the >> password that the client is using to connect, would it then be able to

Hi, This question is interesting and laeds me to another one: As KDC send a ticket to the client when trying to authenticate (something which should decrypted using user's password), is it possible to brute force this initial ticket locally? Mathias 2017-08-15 3:29 GMT+02:00 Andrew Bartlett via samba <samba at lists.samba.org>: > On Mon, 2017-08-14 at 20:26 -0400, Daniel Benoy via

https://bugzilla.mindrot.org/show_bug.cgi?id=1736 Summary: OpenSSH doesn't seem to work with my MuscleCard PKCS#11 library Product: Portable OpenSSH Version: 5.4p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Smartcard AssignedTo:

Robert Wolf wrote: >> else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you >> have enabled something like cram-md5. > > Hi, > > exactly, this is the reason, why plain-text is still needed. You don't need > encryption for authentication, if you have secure authentication. Without > knowing original password, the MITM cannot generate correct hash

On Fri, 2020-09-18 at 15:39 +0200, Marco Gaiarin via samba wrote: > Mandi! Karolin Seeger via samba > In chel di` si favelave... > > > (Both as classic/NT4-style and active direcory DC.) > > I've searched some info on impact of this bug on NT domains, finding > nothing on the net. > > OK, NT domain are dead, i know, but... i seek some feedback. > On real

On Sun, 4 Oct 2020, Christoph Anton Mitterer wrote: > On Sat, 2020-10-03 at 19:44 +1000, Damien Miller wrote: > > Otherwise, feel free to ask me anything. > > Was it ever considered that the feature itself could be problematic, > security-wise? Of course we considered this. > I see at least two candidates: > - It's IMO generally a bad idea to distribute

Hi all. I've looked at the archives and it seems to be quiet regarding this supposed "0-day" openssh vulnerability and I'm wondering if anyone here may have some insight or further information regarding it. We've been monitoring things and the amount of speculative info flying around is incredible. Some claim it's the CPNI-957037 issue, thus affecting <5.2, others

Because of security vulnerabilities in tinc that have recently been discovered, we hereby release tinc versions 1.0.35 and 1.1pre17. Here is a summary of the changes in tinc 1.0.35: * Prevent oracle attacks (CVE-2018-16737, CVE-2018-16738). * Prevent a MITM from forcing a NULL cipher for UDP (CVE-2018-16758). Here is a summery of the changes in tinc 1.1pre17: * Prevent oracle attacks in the

Because of security vulnerabilities in tinc that have recently been discovered, we hereby release tinc versions 1.0.35 and 1.1pre17. Here is a summary of the changes in tinc 1.0.35: * Prevent oracle attacks (CVE-2018-16737, CVE-2018-16738). * Prevent a MITM from forcing a NULL cipher for UDP (CVE-2018-16758). Here is a summery of the changes in tinc 1.1pre17: * Prevent oracle attacks in the

Hi All, My group runs several Samba services in production and we are trying to determine our exposure level to this vulnerability. It is my understanding that, on success, this attack gives read/write access to both the "Local Security Authority" service and to the "Security Account Manager" database(s). From the reading that I've been doing, it looks as though the

Hi, I have the SSH Terrapin Prefix Truncation Weakness on Red Hat Enterprise Linux release 8.7 (Ootpa). The details are as follows. # rpm -qa | grep openssh openssh-8.0p1-16.el8.x86_64 openssh-askpass-8.0p1-16.el8.x86_64 openssh-server-8.0p1-16.el8.x86_64 openssh-clients-8.0p1-16.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.7 (Ootpa) # SSH Terrapin Prefix Truncation

If I read this correctly, starttls will fail due to the MITM attack. That is the client knows security has been compromised. Using SSL/TLS, the MITM can use SSL stripping. Since most Postifx conf use "may" for security, the message would go though unencrypted. Correct??? Is there something to enable for perfect forward security with starttls? ? Original Message ? From: s.arcus at

Lest anyone think STARTTLS MITM doesn't happen, https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/ Not only for security, I prefer port 993/995 as it's just plain simpler to initiate SSL from the get-go rather than to do some handshaking that gets you to the same point. Joseph Tam <jtam.home at gmail.com>

OpenSSH 9.6 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested

I would like to be able to check my bank account while we are on holiday. I know the bank's site is encrypted from the start - the login page is https and Verisign-trust encrypted - but is there any risk in using public wireless networks for jobs like this? It sounds secure enough, but maybe I'm paranoid.... Anne -------------- next part -------------- A non-text attachment was

Am 6. Dezember 2014 13:10:58 MEZ, schrieb Reindl Harald <h.reindl at thelounge.net>: > >Am 06.12.2014 um 06:56 schrieb Jan Wide?: >> If you add disable_plaintext_auth=yes ssl=required settings, then >> dovecot will drop authentication without STARTTLS. But damage will be >> done, client will send unencrypted (or in this scenario MD5 or SHA512 >> hash)

On 02/09/2017 01:11 PM, Leonard den Ottolander wrote: > On Thu, 2017-02-09 at 12:58 -0600, Johnny Hughes wrote: >> At the time of extraction, the <name>.metadata file is created (again, >> not by us, but by the Red Hat team that distributes source), and all the >> non-text sha1sums are in there as well as all the text sources. > > Aha, <name>.metadata, well,

Thunderbird has a MITM vulnerability with its otherwise rather groovy auto-configuration feature. The problem is that it makes requests via HTTP to retrieve the auto configuration information. This allows a black hat (e.g. the NSA) to modify the results sent to the client, and the client has no way to verify the results have not been tampered with. This could even allow the black hat to act

Hello, Which one of these ensures that SIP packets are sent and received in a secure format so that users using public wifi don't allow MITM type of attacks or others can't read the plaintext SIP packet info. VPN is not an option. Looking for 2nd most secure to VPN. P.S. Are both options part of the configs of Asterisk or need modules to be selected and installed before doing the

On 29/05/20 11:27 pm, mj wrote: > Thanks to all who participated in the interesting discussion. > > It seems my initial thought might have been best after all, and > discontinuing port 143 might be the safest way proceed. Yes and no. Some of the attack vectors mentioned are not reasonable and it really depends on the client. Thunderbird, for example, used to have settings for